| View previous topic :: View next topic |
| Author |
Message |
runningwithscissors
Guru
Joined: 21 Apr 2006
Posts: 454
Location: the third world
|
 Posted: Sun Apr 08, 2007 12:44 pm Post subject: [SOLVED] Debugging help |
 |
|
Okay. My program has been segfaulting.
I've run valgrind on it, and this is the cause of failure:
| Code: | Invalid read of size 8
==11910== at 0x4F22140: (within /usr/lib64/libGLU.so.1.3.060501)
==11910== by 0x4F22369: gluUnProject (in /usr/lib64/libGLU.so.1.3.060501)
==11910== by 0x408A16: draw_map (render_objects.c:593)
==11910== by 0x40BCDE: draw_view (render_engine.c:143)
==11910== by 0x40C14D: draw (game_engine.c:15)
==11910== by 0x40CFFC: event_handler (x_event.c:197)
==11910== by 0x40D778: draw_window (x_window.c:156)
==11910== by 0x40D928: main (game.c:37)
==11910== Address 0xA is not stack'd, malloc'd or (recently) free'd
==11910==
==11910== Process terminating with default action of signal 11 (SIGSEGV)
==11910== Access not within mapped region at address 0xA
==11910== at 0x4F22140: (within /usr/lib64/libGLU.so.1.3.060501)
==11910== by 0x4F22369: gluUnProject (in /usr/lib64/libGLU.so.1.3.060501)
==11910== by 0x408A16: draw_map (render_objects.c:593)
==11910== by 0x40BCDE: draw_view (render_engine.c:143)
==11910== by 0x40C14D: draw (game_engine.c:15)
==11910== by 0x40CFFC: event_handler (x_event.c:197)
==11910== by 0x40D778: draw_window (x_window.c:156)
==11910== by 0x40D928: main (game.c:37)
|
And here is the result of running the core dump through the debugger
| Code: | Core was generated by `../bin/game1'.
Program terminated with signal 11, Segmentation fault.
#0 0x00002b2939ff9140 in ?? () from /usr/lib/libGLU.so.1
(gdb) bt
#0 0x00002b2939ff9140 in ?? () from /usr/lib/libGLU.so.1
#1 0x00002b2939ff936a in gluUnProject () from /usr/lib/libGLU.so.1
#2 0x0000000000408da3 in draw_map (map=0x5f9d50) at render_objects.c:593
#3 0x000000000040c0a3 in draw_view (view=0x5f2930) at render_engine.c:143
#4 0x000000000040c512 in draw () at game_engine.c:15
#5 0x000000000040d431 in event_handler () at x_event.c:197
#6 0x000000000040dba7 in draw_window () at x_window.c:156
#7 0x000000000040dd59 in main (argc=1, argv=0x7fff70fe2278) at game.c:37 |
I suspect my program is overwriting memory blocks that it shouldn't, but I don't know where it is happening.
Any idea how I can pinpoint the exact cause of the problem?
Any help would be appreciated. I am not exactly the most experienced user when it comes to debugging tools.
Last edited by runningwithscissors on Sun Apr 08, 2007 4:50 pm; edited 1 time in total |
|
| Back to top |
|
 |
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23093
|
| Posted: Sun Apr 08, 2007 4:06 pm Post subject: |
|
|
According to the messages from Valgrind, libGLU is dereferencing a bad pointer. Check the value of the parameters you are passing to gluUnProject, as well as any values pointed to by those parameters. The line Address 0xA is not stack'd, malloc'd or (recently) free'd suggests that the problem is most likely a NULL pointer with a small offset, as could happen if you had a structure with a member at +0xa, and passed NULL for the pointer to the structure.
If you are willing to spend some extra disk space, you could re-emerge libGLU with debugging symbols and optionally with source installed. The former will get you much more precise backtraces. The latter will let you do source-level debugging with sys-devel/gdb, even when your program steps into libGLU. You can use gdb on your program without either of these steps, but it will be more difficult to follow execution into libraries for which gdb cannot find the symbols. It has been a long time since I worked with symbols, but without source. If I remember correctly, in that situation, you can perform stepping based on source lines, but gdb cannot show you the source corresponding to the code you are about to execute.
See How to get meaningful backtraces in Gentoo for instructions on how to get debugging symbols into packages installed by Portage. See also the manpage for make.conf regarding the feature installsources. |
|
| Back to top |
|
|
runningwithscissors
Guru
Joined: 21 Apr 2006
Posts: 454
Location: the third world
|
| Posted: Sun Apr 08, 2007 4:45 pm Post subject: |
|
|
Thanks for your reply.
I found what was causing the problem.
OpenGL's GLdouble datatype doesn't like the decimal point omitted from the values you're passing (which I was passing through gluUnProject). Rather innocuous after all.
Also, thanks for the nice link about including better debug support in libs installed through portage.  |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
