gdb/2036: cannot access errno when debugging core files created with gcore on GNU/Linux (RHEL-3, gdb 6.0post-0.20031117.6rh and GNU gdb 6.3)

Michael.Zraly@openwave.com Michael.Zraly@openwave.com
Sat Nov 19 14:08:00 GMT 2005


>Number:         2036
>Category:       gdb
>Synopsis:       cannot access errno when debugging core files created with gcore on GNU/Linux (RHEL-3, gdb 6.0post-0.20031117.6rh and GNU gdb 6.3)
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Nov 19 14:08:01 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Michael.Zraly@openwave.com
>Release:        GNU gdb 6.3
>Organization:
>Environment:
Linux email-devlnx08 2.4.21-9.ELsmp #1 SMP Thu Jan 8 17:08:56 EST 2004 i686 i686 i386 GNU/Linux
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-24)
This GDB was configured as "i686-pc-linux-gnu".
>Description:
I have a multithreaded process.  If I attach to it and try to print the value of the thread-local value errno while attached to the process, it works fine.  However, if I run gcore to save a core file, detach from the running process, then run the debugger against the executable using the core file, I get this error when I try to print the value of errno:

Cannot access memory at address 0xb6e8c008

The address mentioned in the error message, 0xb6e8c008, falls within libc thread-local storage.  Here is the relevant line from /proc/18549/maps:

b6e8c000-b6fbe000 r-xp 00000000 08:02 16098      /lib/tls/libc-2.3.2.so

Perhaps the gcore command doesn't save this part of memory?  It doesn't look that way.  If I run the command "set verbose" before running gcore, I can see this output, indicating that the tls data is being saved:

Save segment, 1253376 bytes at 0xb6e8c000 (r x) for       /lib/tls/libc-2.3.2.so
Save segment, 1253376 bytes at 0xb6e8c000

On further investigation, thoug, it looks like the gcore_create_callback() function (in gcore.c) clears the SEC_LOAD flag for this segment, probably because it is associated with a file that is mapped into memory.  But when gdb is run against the executable and gcore-produced core file, it claims read and load symbols from /lib/tls/libc.so.6 (which is linked to /lib/tls/libc-2.3.2.so), so I wouldn't have expected this to be a problem.
>How-To-Repeat:
1. Run a multithreaded process, e.g. a server of some sort.
2. Start gdb with no arguments
3. Attach to the process
4. Create a core file using the gcore command
5. Detach from the process
6. Quit gdb
7. Restart gdb, with the server executable and newly-created core file as arguments.
8. Enter the gdb command "print errno"

This should produce the value of errno in the current thread.  Instead, I see an error message.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:



More information about the Gdb-prs mailing list