Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ Programming ➜ General ➜ Gdb didn't catch segfault?
Gdb didn't catch segfault?

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1 2  3  

Posted by Zeno   USA  (2,871 posts)  Bio
Date Sun 26 Mar 2006 05:19 AM (UTC)
Message
So my Project CR seems to crash like once every 3 days. So I attached gdb to it and let it run. 3 days later, it crashes.
(gdb) c
Continuing.
Segmentation fault

(Between continue and segfault was 3 days)

Er. Why didn't it go into a backtrace? It also didn't dump a core.
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
Top
Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #1 on Sun 26 Mar 2006 05:27 AM (UTC)
Message
Did you compile with debugging enabled? See my post about gdb for details. Also ensure you remove the stuff inside SMAUG that catches segmentation faults (see the same post).

Before waiting 3 days, simulate a crash (make a command dereference nil or something) and check that you are catching it.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Zeno   USA  (2,871 posts)  Bio
Date Reply #2 on Sun 26 Mar 2006 05:33 AM (UTC)
Message
Simulating a crash produces a core, I've tested that. This isn't Smaug by the way. Yes, my Makefile has -g3 in it.
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #3 on Sun 26 Mar 2006 09:01 AM (UTC)
Message
Could the segfault be in a thread or attached process, perhaps? It's possible that if it's not your process that's dying, gdb won't catch it properly. That being said, if it crashes enough to kill the program, it should crash enough to make gdb catch it...

Are you using threads/attached processes in the first place? You're using MySQL, right? Maybe it's an issue with that...
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Zeno   USA  (2,871 posts)  Bio
Date Reply #4 on Sun 26 Mar 2006 04:05 PM (UTC)
Message
This is the only process for it, but I do think it uses threads... Not that I have any idea what they are. Not using MySQL.
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
Top
Posted by Samson   USA  (683 posts)  Bio
Date Reply #5 on Mon 27 Mar 2006 12:35 PM (UTC)
Message
If you are running from inside gdb, then it won't generate a backtrace upon a segfault, you need to tell it to do that afterward. You would still be within a live run of the game at that point.

Of course if the crash was bad enough to kill the debugger too, that's going to be difficult to track down unless you know how to make it happen.
Top
Posted by Zeno   USA  (2,871 posts)  Bio
Date Reply #6 on Mon 27 Mar 2006 02:17 PM (UTC)
Message
I should have been more specific. The debugger was no longer running, and I was back into bash.
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
Top
Posted by Nick Cash   USA  (626 posts)  Bio
Date Reply #7 on Mon 27 Mar 2006 03:26 PM (UTC)
Message
Try adding some simple log statements (or print statements and redirect the output) to the latest code additions. Print out the values of things. Chances are you have a corrupt pointer somewhere.
~Nick Cash
http://www.nick-cash.com
Top
Posted by Zeno   USA  (2,871 posts)  Bio
Date Reply #8 on Mon 27 Mar 2006 05:22 PM (UTC)
Message
I haven't added code to it in... months. Another note is that nothing happens on the MUD for those 3 days.
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #9 on Mon 27 Mar 2006 07:56 PM (UTC)
Message
If this started happening since the Arthmoor upgrades, I'd make sure that you recompiled [i]every single object file[/i] that you have to make sure that everything is linking against the proper libraries etc. It's possible that if you have old libraries, something ever so slightly incompatible exists in some obscure location.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Zeno   USA  (2,871 posts)  Bio
Date Reply #10 on Mon 27 Mar 2006 07:57 PM (UTC)
Message
Nah, Project CR isn't on Arthmoor. It's on my own machine.
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #11 on Mon 27 Mar 2006 08:06 PM (UTC)
Message
Well, the same thing applies if you upgraded kernel, C runtime libraries, g++, anything... You never know. (Even if you're running under e.g. Cygwin)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Zeno   USA  (2,871 posts)  Bio
Date Reply #12 on Tue 28 Mar 2006 01:20 AM (UTC)
Message
I haven't upgraded anything. Could you explain (or link to) details about threads? I'm pretty sure there was a mention of threads when I originally ran the exec with gdb which I've never seen.
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #13 on Tue 28 Mar 2006 01:45 AM (UTC)
Message
My understanding is that gdb doesn't behave very well with threads. I had several class projects that we had to debug the old-school, old-fashioned way by hand because gdb couldn't work with the threads. Apparently, if one thread crashes it doesn't always bring you to the thread that crashed, but it'll interrupt the "main thread", or something odd like that.

It's possible that it's just the version of gdb we were using, but I've heard from several people in several places that gdb doesn't behave too well. Unfortunately I don't have any articles or manuals lying around that would explain it.

It's just very strange that it doesn't seem to do anything at all. You say that when you run it without gdb, it doesn't crash?

Maybe what you could do is add log entries to all kinds of places all over the code, like when the update function is run etc. That might at least help track down what part of the code is dying -- that is getting closer to the old-fashioned way of debugging things. :-)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Zeno   USA  (2,871 posts)  Bio
Date Reply #14 on Tue 28 Mar 2006 01:49 AM (UTC)

Amended on Tue 28 Mar 2006 02:01 AM (UTC) by Zeno

Message
Nah, it'll crash after ~3 days with or without gdb attached.

This is what I meant by seeing threads:

(gdb) run
Starting program: /home/zeno/chub/src/chub
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 26181)]


Now if I do Ctrl+C:

Program received signal SIGINT, Interrupt.
[Switching to Thread 16384 (LWP 26181)]
0x401723c2 in select () from /lib/libc.so.6



(gdb) bt
#0  0x401723c2 in select () from /lib/libc.so.6
#1  0x00000006 in ?? ()
#2  0x00000000 in ?? ()
#3  0xbffff710 in ?? ()
#4  0x0804953c in game_loop (control=0) at socket.c:227
#5  0x08049294 in main (argc=1, argv=0xbffff794) at socket.c:79


Continue:

(gdb) c
Continuing.
[New Thread 32769 (LWP 26183)]
[New Thread 16386 (LWP 26184)]
[Thread 16386 (LWP 26184) exited]
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

79,478 views.

This is page 1, subject is 3 pages long: 1 2  3  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home