Re: flwrapper on Opteron

Am Tuesday 28 February 2006 20:07 schrieb Michael Obster:
> Hi Stefan,
>
> Stefan Fiedler schrieb:
> > please give some more details about your system and how to reproduce the
> > bug. Which ROCK tree do you use, and on which system (distro) do you
> > build?
>
> It's current trunk when building in 64-bit userland (building in 32-bit
> userland does not show this bug).
>
> The bug happens when the system changes into the chroot from stage 2 to
> 3. The first thing before any package is build in stage 3 is a rebuild
> of the buildtools (where flwrapper.so is part). Because we have no log
> of this process I cannot give any more exact information.
> I think the bug happens, when flwrapper.so is preloaded after building
> and the first operations are started, because the error message is a
> runtime error message, so s.th. must execute flwrapper.so.
>

There's only one occurrence of free() in /misc/tools-source/fl_wrapper.c 
(which is created from the corresponding .sh file):

/misc/tools-source/fl_wrapper.c{,.sh}:
		char buf[512], *buf2, *logfile;
		...
		buf2=get_current_dir_name();
		...
		free(buf2);

According to the man pages of "3 get_current_dir_name" and "3 free", 
get_current_dir_name() should malloc() a buffer and store it in buf2, which 
is later on (correctly) freed.
free() requires a void * as argument, while buf2 is a char *; you could try an 
explicit type cast and replace 
		free(buf2);
with
		free((void *)buf2);

Hope that helps,
	Stefan Fiedler

> Some system information:
> Siemens Fujitsu
> Opteron 144
> See https://www.server4you.de/de/d/index.html (Root Power)
> I'll attach a lspci output.
>
> Cheers,
> Michael