[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


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:


* 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?

Steven Chamberlain

Reply to: