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

Re: Sources for tracing into standard libraries + apt-get source versioning



Lee Braiden <jel@tundra.ath.cx> writes:

> Ross,
>
> I can't help much on apt policy issues, but...
>
> On Tuesday 26 April 2005 21:16, Ross Boylan wrote:
>> I am trying to track down an apparent memory problem and, in a move of
>> some desperation, though it might be useful to trace into the source
>> where the failure occurs (or is noticed).  That's in libc, called from
>> libstdc++, as shown in this gdb stack trace
>> #0  0x401c02cb in _int_free (av=0x4027e060, mem=0x809e2f8) at
>> malloc.c:4209
>> #1  0x401bf09f in __libc_free (mem=0x809e298) at malloc.c:3359
>> #2  0x400f85b3 in operator delete (ptr=0xc00b3333)
>>     at ../../../../src/libstdc++-v3/libsupc++/del_op.cc:39
>> #3  0x0804e05b in __valarray_release_memory (__p=0x809e298) at
>> valarray_array.h:70
>
> I think it's probably safe to assume that the standard libc free() and stdc++ 
> delete calls work OK.  If it was me, I'd be looking at what's being passed to 
> those calls: what's actually getting deleted, why it's getting deleted, and 
> what else might be using that object/memory, for whatever reason.

Wise words. OP was kind enough to give us the callstack from libstdc++
downwards, but no word about the application he actually run, and which
freed that memory presumably giving a bad pointer. Nor any word about
the signal received, presumably SIGSEGV. Either way, this is almost
certainly an application bug, and hunting for the the libc sources a
waste of time. If any sources, pull those for your app first, and then
see there what is passed down into libc.

Regards, Bruno.



Reply to: