--- Begin Message ---
Package: gcc-4.1
Version: 4.1.2-15
Severity: important
Compiling xmlrpc-c CVS from <URL:http://xmlrpc-c.sourceforge.net/>
results in a broken xmlrpc library that fails to allocate memory for the
structs.
We have this call to realloc in src/method.c
static __inline__ void
reallocProduct(void ** const blockP,
unsigned int const factor1,
unsigned int const factor2) {
if (UINT_MAX / factor2 < factor1)
*blockP = NULL;
else
*blockP = realloc(*blockP, factor1 * factor2);
}
#define REALLOCARRAY(arrayName, nElements) \
reallocProduct((void **)&arrayName, nElements, sizeof(arrayName[0]))
REALLOCARRAY(signatureP->argList, minArgCount);
if (signatureP->argList == NULL) {
// ...
This results in:
movl 16(%esi), %eax
movl %eax, (%esp)
call realloc@PLT
.LVL80:
.LBE129:
.loc 1 72 0
movl 16(%esi), %ecx
testl %ecx, %ecx
.LBB130:
.LBB131:
.loc 3 57 0
movl %eax, 16(%esi)
.LBE131:
.LBE130:
.loc 1 72 0
jne .L97
On 1 Sep 2007 02:41:57 +0000, Bryan Henderson <bryanh@giraffe-data.com> wrote:
> It calls realloc(), which returns its return value in register %eax.
> It tests 16(%esi) for NULL, and THEN copies %eax to 16(%esi).
>
> So where it thinks it's testing the return value, it's really testing
> the argument of realloc(), which is NULL here, and it thinks realloc()
> returned NULL.
>
>
> I saw a reordering of code similar to this in Gcc 2.96 many years ago.
> It was because Red Hat had decided to ship a major release with an
> untested prerelease version of Gcc. It caused pain for a couple of
> years;
--- End Message ---
--- Begin Message ---
On 9/1/07, Falk Hueffner <falk@debian.org> wrote:
> Unfortunately, you did not send a complete test case, so this is hard
> to tell, but it looks like an aliasing violation in your code.
> "*blockP" accesses an lvalue of type "void*", while its actual type is
> probably some other pointer type; that is not allowed.
>
> Please test whether the problem goes away with -fno-strict-aliasing.
> If not, please provide a complete test case.
I've forwarded your response to the author of that library and he now
acknowledges that it might be a fault on his side.
Thank you very much for pointing out the obvious and apologies for the
inconvenience causes.
This was solved by -fno-strict-aliasing as you suggested.
--- End Message ---