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: