0

I'm working on RHEL WS 4.5.

I've obtained the glibc source rpm matching this system, opened it to get its contents using rpm2cpio.

Working in that tree, I've created a patch to mtrace.c (i want to add more stack backtrace levels) and incorporated it in the spec file and created a new set of RPMs including the debuginfo rpms.

I installed all of these on a test vm (created from the same RH base image) and can confirm that my changes are included.

But with more complex executions, I crash in mtrace.c ... but gdb can't find the debug information so I don't get line number info and I can't actually debug the failure.

Based on dates, I think I can confirm that the debug information is installed on the test system in /usr/src/debug/glibc-2.3.6/

I tried sharedlibrary libc* in gdb and it tells me the symbols are already loaded.

My test includes a locally built python and full symbols are found for python.

My sense is that perhaps glibc isn't being built under rpmbuild with debug enabled. I've reviewed the glibc.spec file and even built with

_enable_debug_packages

defined as 1 which looked like it might influence the result. My review of the configure scripts invoked during the rpmbuild build step didn't give me any hints.

Hmmmm .. just found /usr/lib/debug/lib/libc-2.3.4.so.debug and /usr/lib/debug/lib/tls/i486/libc-2.3.4.so.debug but both of these are reported as stripped by the file command.

Nikhil
  • 16,194
  • 20
  • 64
  • 81
David Morris
  • 1
  • 1

2 Answers2

0

It appears that you are installing non-matching RPMs:

/usr/src/debug/glibc-2.3.6
just found /usr/lib/debug/lib/libc-2.3.4.so.debug

There are not for the same version; there is no way they came from the same -debuginfo RPM.

both of these are reported as stripped by the file command.

These should not show as stripped. Either they were not built correctly, or your strip is busted.

Also note that you don't actually have to get all of this working to debug your problem. In the RPMBUILD directory, you should be able to find the glibc build directory, with full-debug libc.so.6. Just copy that library into your VM, and you wouldn't have to worry about the debuginfo RPM.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Wow ... not sure why I didn't notice the 2.3.6 vs. 2.3.4 discrepancy. I just redid the rpm2cpio | cpio extract of: – David Morris Oct 31 '12 at 20:31
  • Let me try again ... the so web site isn't letting me use the carriage return key in – David Morris Oct 31 '12 at 20:35
  • I just did a trial repeat of the rpm2cpio extract of: SRPMS/glibc-2.3.4-2.36.src.rpm from the RHWS4.5 install .iso ... the source tarball inside is: glibc-2.3.6.tar.bz2 ... I then did `rpm -qf` for one of the 2.3.6 files installed with yesterdays date and learned they came from a 2.3.4 rpm. So it would seem that RH has issues inside of the source RPM with a 2.3.4/2.3.6 confusion. – David Morris Oct 31 '12 at 20:45
  • Sorry about breaking this up but I'm not able to add paragraphs. – David Morris Oct 31 '12 at 20:46
  • I shall try your suggestion re. using the build libc*.so directly. In the end, all I care about is being able to debug my change. – David Morris Oct 31 '12 at 20:48
0

Try verifying that debug info for mtrace.c is indeed present. First see if the separate debug info for GLIBC knows about a compilation unit called mtrace.c:

$ eu-readelf -w /usr/lib/debug/lib64/libc-2.15.so.debug  > t
$ grep mtrace t
           name                 (strp) "mtrace.c"
             name                 (strp) "mtrace"
 1     0     0         0         mtrace.c
 [10480]  "mtrace.c"
 [104bb]  "mtrace"
 [5052] symbol: mtrace, CUs: 446

Then see if GDB actually finds the source file from the glibc-debuginfo RPM:

(gdb) set pagination off
(gdb) start # pause your test program right after main()
(gdb) set logging on
Copying output to gdb.txt.
(gdb) info sources

Quit GDB then grep for mtrace in gdb.txt and you should find something like /usr/src/debug/glibc-2.15-a316c1f/malloc/mtrace.c

This works with GDB 7.4. I'm not sure the GDB version shipped with RHEL 4.5 supports all the command used above. Building upstream GDB from source is in fact easier than Python though.

When trying to add strack traces to mtrace, make sure you don't call malloc() directly or indirectly in the GLIBC malloc hooks.

scottt
  • 7,008
  • 27
  • 37