Re: Bug#685625: implicit declaration of function ‘reallocf’
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
steven@pyro.eu.org
Reply to: