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.
Can you try the current gdb from Rawhide?
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.
Simple binaries work with current Rawhide... haven't found anything not working yet.
glibc and compiler is also uptodate?
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.
A couple of questions first: You use pthreads?
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); }
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)
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.
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.
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?