Control: severity -1 grave Control: affects -1 grub-common Control: retitle -1 [kfreebsd] libgeom: may cause segfault of grub-probe
Hello, On 21/12/12 18:45, Jeff Epler wrote: > geom_getxml.c: In function ‘geom_getxml’: > geom_getxml.c:59:2: warning: implicit declaration of function ‘reallocf’ > [-Wimplicit-function-declaration] > geom_getxml.c:59:2: warning: return makes pointer from integer without a cast > [enabled by default] > > On kfreebsd-amd64 systems, the consequence of this is that the top 32 > bits of a pointer returned by reallocf are discarded. Curiously I have never been affected by this on kfreebsd-amd64. My kern.geom.confxml is only ~16 KiB. The reporter could reproduce this reliably with a kern.geom.confxml of ~4 MiB. I observe some magic threshold of 136648 bytes, above which malloc() in a simple C program starts to return an address with some of the high 32 bits set, triggering the bug. I think the chance of this being a problem during install is very low, unless there is some large pre-existing ZFS pool. On an installed system, it would become impossible to update/upgrade GRUB after exceeding some number of ZFS volumes * snapshots (I guess around 500, but deleted snapshots still seem to count - that may also be a bug). Therefore I'm raising the severity of this. It's not unreasonable to have 50 zvols (one per user/share on a NAS, for example), and if taking weekly snapshots this could trigger after 10 weeks; if daily, 10 days; if hourly, 10 hours etc. > - -D__va_list=__builtin_va_list > + -D__va_list=__builtin_va_list \ > + -Werror=implicit-function-declaration That's a good idea. The buildd log scanner reveals a handful more cases of this compiler warning in other GNU/kFreeBSD packages which we should probably look into: https://buildd.debian.org/~brlink/bytag/E-pointer-trouble-at-implicit.html * freebsd-buildutils * freebsd-libs * freebsd-utils And I'm worried about some of the other packages mentioned, where the error shows on kfreebsd-* or maybe hurd-*, but not on other arches. Should they really all be doing this: > ++#include <bsd/stdlib.h> Or should we be trying to fix this elsewhere, in GNU/kFreeBSD headers maybe? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org