Summary: | sys-apps/arrayprobe-2.0-r2: Early stable for memleak/double init fixes | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tobias Klausmann (RETIRED) <klausman> |
Component: | New packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | Keywords: | STABLEREQ |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Patch to fix memleak and malloc
detach IDA driver headers from kernel and use them locally |
Description
Tobias Klausmann (RETIRED)
2010-01-13 11:24:33 UTC
Created attachment 216343 [details]
Patch to fix memleak and malloc
+ 13 Jan 2010; <chainsaw@gentoo.org> +files/2.0-malloc-strlen.patch, + +arrayprobe-2.0-r1.ebuild: + Patch scavenged from Ubuntu by Tobias "Blackb rd" Klausmann + <klausman@gentoo.org> resolves a misplaced bracket in a strlen statement + and removes a malloc that does not belong. From bug #300819. Arches, could you (compile) test this package and consider it for early stable please. The previous release has stability problems due to bad coding and I would like to eradicate it from the tree. If you have the hardware (Compaq/HP IDA/CCISS RAID controller) then testing with the actual hardware is of course appreciated. Created attachment 216358 [details, diff]
detach IDA driver headers from kernel and use them locally
I've added a patch that removes the necessity to include files from /usr/src/linux* (which we shoudln't do anyway). Normally, I'd expect such an API to be exported via linux-headers to /usr/include/linux. This actually is the case for the CCISS driver, but not so for the older IDA driver.
Hence, this patch includes copies of the corresponding headers and mucks about with the configure.ac checks and the includes of probe.c to fix all that.
Yes, it's ugly. But it works. And I don't see the ida API being exported all that soon.
It works and passed the tests on one of my cpq-servers (x86) with a 2.6.18-gentoo-r6 kernel. There it worked without problems and i was able to check the array! But on another machine with the latest stable gentoo-sources-2.6.31-r6 i had to adjust /usr/src/linux/include/asm-generic/int-ll64.h (its asm-generic/bitsperlog.h and not asm/bitsblabla) to get the configure-script working! This seems to be still an issue in vanilla-sources-2.6.33_rc3!!?! Imho that should go upstream as its clearly a kernel-bug! (In reply to comment #5) > But on another machine with the latest stable gentoo-sources-2.6.31-r6 i had to > adjust /usr/src/linux/include/asm-generic/int-ll64.h (its > asm-generic/bitsperlog.h and not asm/bitsblabla) to get the configure-script > working! This seems to be still an issue in vanilla-sources-2.6.33_rc3!!?! > Imho that should go upstream as its clearly a kernel-bug! That's not a kernel bug exactly. User space programs shouldn't use the kernel header files directly. Arrayprobe does this because it needs to use the IDA driver ioctls. By contrast, the CCISS ioctls are available via /usr/include/linux. I've committed a new ebuild (2.0-r2) which includes the (fixed) headers and does not use the kernel sources anymore. Can you sync and test that (it might still take two hours or so until the ebuild turns up on the Rsync servers, but it's in our CVS. > It compiles with the ~x86 sys-app/linux-headers-2.6.30-r1, but i can't test it really right now... I will do that tomorrow morning (emerge-webrsync at the company...) But to be warned: That wrong include-path within the linux-header-file wasn't there at least till 2.6.30-r9... I assume that when new headers are getting bumped, they're screwed as well! :-/ ok, i tested x86 on ida and cciss servers with different Kernel and header versions now, it works flawless! x86 stable, thanks Andreas amd64 stable |