Re: Sources for tracing into standard libraries + apt-get source versioning
On Wed, Apr 27, 2005 at 02:04:35AM +0200, Bruno Hertz wrote:
> 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.
>
Sorry I was unclear. I don't want the sources because I think the bug
is in the libs. I want them because I assume the libs are checking
and finding something is wrong. I'm trying to get more information
about what they find is wrong. I believe the signals are being
deliberately thrown by the libs to alert me that something is amiss.
I need exactly the right sources to relate the traces I'm seeing to
the tests. For example, the malloc.c line in frame 0 is, using the
sources I have, in the middle of the function declaration for
_int_free, rather than being down at one of the tests it makes to
check integrity. But the source I'm looking at is the wrong version
and doesn't have the debian patches applied, so it's not a good guide.
I am having some luck pinning the bug down with mpatrol. In my first
attempts, the bug went away as soon as I ran under mpatrol. Quite a
puzzle. I would have preferred to instrument the program and get an
immediate result like "you're trying to free the same memory twice."
Unfortunately, that didn't happen. Hence the indirect route.
Reply to: