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

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



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 installed the -dbg versions of the relevant libraries, but that gets
me the symbols, not the code.

How do I get the source that exactly matches the libraries I'm using
(testing)?

I did
apt-get  -t testing source libc6 libstdc++5
but am concerned about a couple of things.

First, is this exactly the right version?  The version numbers that are
being downloaded, and that appear in the changelog, differ from those
shown for my current packages.  For example libc6 is 2.3.2.ds1-20, but
the downloaded source (glibc) is 
Get:3 http://ftp.us.debian.org ../project/experimental/main glibc
2.3.5-1 (dsc) [1710B]

Is this an apt-get bug?  A misunderstanding on my part of how it's
supposed to work?

I do have sources in unstable and experimental in my sources.list, and
initially did not have testing.  I added it when my initial attempt
seemed to pull in the wrong version, but neither that (and an update)
nor the -t option seem to have made a difference.

My /etc/apt/preferences is
--------------
Package: *
Pin: release a=testing
Pin-Priority: 600

Package: *
Pin: release a=unstable
Pin-Priority: 50

Package: *
Pin: release a=experimental
Pin-Priority: 40
-------------------


Second, having obtained the packages, how do I get it to construct the
sources without doing a full build?



Reply to: