arrayprobe has been failing for me recently (segfaults, glibc free() errors and assertions in glibc failing). I poked around the source with the help of valgrind and found two bugs, a memleak and a paren error that makes a malloc go boom. The memleak is in main(), lines 482 and 521 are redundant: the first mallocs() and the second does exactly the same but in between, there isn't a single mention of the variable the memory has been allocated for (logdrvs). The second is in line 357. If you look closely, you'll see that the +1 near the end is inside strlen's parens, which obviously is wrong, it should be right behind them. I'll attach a patch that fixes both. Fwiw, Ubuntu found the same bug and fixed it already, Debian has a bug open for it (514028) but hasn't yet released a fixed version.
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
khm... https://bugs.gentoo.org/show_bug.cgi?id=297068
amd64 stable
