[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Detecting Seg faults
- To: linuxgames@sunsite.dk
- Subject: Detecting Seg faults
- From: Francesco Orsenigo <xarvh@lombardiacom.it>
- Date: Tue, 19 Oct 2004 18:21:45 +0200
- Delivered-to: archiver@seul.org
- Delivered-to: mailing list linuxgames@sunsite.dk
- Delivery-date: Tue, 19 Oct 2004 12:16:19 -0400
- Mailing-list: contact linuxgames-help@sunsite.dk; run by ezmlm
- Organization: Xarvh Project
- Reply-to: linuxgames@sunsite.dk
- User-agent: KMail/1.7
My program is killed by a segmentation fault at random points.
Which means:
I compile it, i run and it crash at a certain point.
Then i run it again, and it crashes at another.
Running it again and again I usually get the crash at the latter point.
Crash points change also when i change compilation options ("-O3 -s" vs "-g")
or add debug printf()s inside the code to monitor what's happening.
All crashes appear to actually happen when calling malloc() / calloc().
That's the GDB backtrace from the last segmentation fault:
#0 0x4016f3de in mallopt () from /lib/libc.so.6
#1 0x4016ec18 in mallopt () from /lib/libc.so.6
#2 0x4016de03 in malloc () from /lib/libc.so.6
#3 0x40055bc6 in glXChannelRectSyncSGIX () from /usr/lib/libGL.so.1
This leads me to suppose that some part of the code writes something it should
not write and this is detected only when memory is allocated (the seg fault
appears even if a quit from the game beyond a certain point, due to a call to
free() i suppose).
How can i find the point where the bad dereference happens, if the program is
not crashing there?
Is there a way to force a more strict memory check?
I don't know how to use debugging, but it seems that it can't help track
something happening far away from the fault, or am i wrong?
Any idea?
Thanx,
Francesco Orsenigo