Bug 23454 - gdb cannot debug my statically linked binary
gdb cannot debug my statically linked binary
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: gdb (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-05 19:44 EST by William Shubert
Modified: 2007-04-18 12:30 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-28 19:25:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description William Shubert 2001-01-05 19:44:19 EST
I have a largish program which I build on a red hat 7 machine and run on a
red hat 6.2 machine (the run machine is server that it is important to have
on-line at all times, so I haven't upgraded it yet). Because of this, I
must statically link to make binaries that I can build on RH 7 and then run
on the RH 6.2 server.

Recently a server binary crashed when on the RH7 build/test machine. When I
tried to debug it, I got this message after "gdb bin/igoweb-d" and before
typing a single command:

	warning: Unable to set global thread event mask: generic error
	[New Thread 1024 (active)]
	Cannot enable thread event reporting for Thread 1024 (active): generic
error
	(gdb)

Then when I try to load the core (as the first command I type), I get:

	(gdb) core-file core
	Core was generated by `bin/igoweb-d'.
	Program terminated with signal 6, Aborted.
	warning: you won't be able to access this core file until you terminate
	your multi-threaded child process.; do ``info files''
	(gdb) 

"info files" told me nothing that I understood. I have no idea what it is
talking about when it mentions my "multi-threaded child process". This
program does make pthreads calls, but it does not create any threads (it is
a config option to spawn extra threads, I don't usually do it though). Any
idea what is going on here? This happens under RH 7 with all the latest
updates; then I tried the version of gdb in rawhide (gdb-5.0-11), same
problem.

When I tried recompiling without the "-static" switch, gdb was able to load
and examine the program fine, but this is not a good workaround because
that means any core dumps from the production system (which must be
statically linked since it is RH 6.2) will not be debuggable.
Comment 1 Trond Eivind Glomsrxd 2001-01-08 11:02:49 EST
Can you try the current gdb from Rawhide?
Comment 2 William Shubert 2001-01-08 11:11:15 EST
Yes, as I said in my original comment, after the RH7 version failed I tried the
latest rawhide version (gdb-5.0-11.i386.rpm) and got exactly the same result.
Comment 3 Trond Eivind Glomsrxd 2001-01-08 11:20:56 EST
Simple binaries work with current Rawhide... haven't found anything not working
yet.
Comment 4 Trond Eivind Glomsrxd 2001-01-08 11:21:42 EST
glibc and compiler is also uptodate?
Comment 5 William Shubert 2001-01-08 11:29:08 EST
Here's what I have (just ran up2date about a week ago so I think they are the
latest):

$ rpm -q glibc gcc
glibc-2.2-9
gcc-2.96-69
$ 

I would be able to send you a core and a compiled binary. It is a non-free
application, so I can't post it publicly, but if it would help you to see gdb
fail to read the application (and I assume it would!), then I can email it to
you. (I just tried a few trivial cases too, and you are right - they work fine).
Anyway, let me know if you would like me to send it to you.
Comment 6 Trond Eivind Glomsrxd 2001-01-08 11:45:31 EST
A couple of questions first: You use pthreads?
Comment 7 William Shubert 2001-01-08 11:57:03 EST
Aha! That was it. My earlier "small examples" were not actually linking in
pthreads, because all the pthreads calls they used were macros. Here's an
example program that clearly shows the problem. Compile as the comment says,
then run it (it will dump core), then try debugging it with gdb and you will see
that gdb refuses to read the core.

/*
 * Compile with: gcc -static -Wall -ggdb gdbt.c -lpthread -o gdbt
 */

#include <stdio.h>
#include <pthread.h>

static int *x = NULL;

int main(int argc, char *argv[]) {
  printf("Testing...should dump core here.\n");
  *x = 0;
  if (x != NULL) {
    /* This is here only to make sure pthread library gets linked in. */
    pthread_create(NULL, NULL, NULL, NULL);
  }
  return(0);
}

Comment 8 Trond Eivind Glomsrxd 2001-01-08 15:10:24 EST
You are in for a problem - Linux doesn't handle multithreaded core files
AFAIK(at least, I know it didn't and I don't think that has changed)
Comment 9 William Shubert 2001-01-08 16:10:22 EST
Actually, linux multithreaded programs do dump core, it is just that there is
only one thread (the last to exit) whose context is available. And since the
example program only has one thread (the original), its core file should work
fine. Try taking out the "-static" and suddenly it is completely debuggable! It
seems to me that whether "-static" was used or not, gdb should still work the
same - isn't that reasonable? After all, we have essentially the same binary
image, just in one case the .so's are part of the core, in the other case, gdb
loads them in at debug time.
Comment 10 Trond Eivind Glomsrxd 2001-03-16 15:58:45 EST
Sorry, but that work around doesn't help: Multithreaded coredumps don't work
under Linux, FTTB. If you look in the latest 2.4 ac kernels, you'll find that
there is some work going on in that area, but I don't expect that to be fully
working for some time yet.
Comment 11 William Shubert 2001-03-19 15:15:37 EST
But what I keep trying to say is that this is NOT a multithreaded program, it is
a single threaded program that happens to be statically linked to the pthreads
library.

As another point I found out, it turns out that under gdb 4.18 it works fine.
Only gdb 5.0 and later have trouble. Shouldn't anything that worked under gdb
4.x also work under 5.x?

Note You need to log in before you can comment on or make changes to this bug.