Elysian Shadows

Posted: **Mon Apr 26, 2010 9:51 pm**

I ran my code in a debugger because I got a segmentation fault, and the output is in hex, the problem seems to be Address 0x0 is not stack'd, malloc'd or (recently) free'd, but how do I tell what that is?

Code: Select all

==3818== Memcheck, a memory error detector
==3818== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==3818== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==3818== Command: ./test -v --leak-check=full
==3818== 
==3818== Conditional jump or move depends on uninitialised value(s)
==3818==    at 0x409B92C: ??? (in /usr/lib/libSDL-1.2.so.0.11.2)
==3818==    by 0x4074355: ??? (in /usr/lib/libSDL-1.2.so.0.11.2)
==3818==    by 0x4046965: SDL_InitSubSystem (in /usr/lib/libSDL-1.2.so.0.11.2)
==3818==    by 0x4046A36: SDL_Init (in /usr/lib/libSDL-1.2.so.0.11.2)
==3818==    by 0x8048DC5: engine::init() (in /home/pythip/Desktop/engine/anim/test)
==3818==    by 0x80497E8: main (in /home/pythip/Desktop/engine/anim/test)
==3818== 
==3818== Invalid read of size 4
==3818==    at 0x40FB3F8: TTF_SizeUNICODE (in /usr/lib/libSDL_ttf-2.0.so.0.6.3)
==3818==    by 0x40FC3BE: TTF_RenderUNICODE_Solid (in /usr/lib/libSDL_ttf-2.0.so.0.6.3)
==3818==    by 0x40FC84F: TTF_RenderText_Solid (in /usr/lib/libSDL_ttf-2.0.so.0.6.3)
==3818==    by 0x804912D: graphics::load_files() (in /home/pythip/Desktop/engine/anim/test)
==3818==    by 0x804980C: main (in /home/pythip/Desktop/engine/anim/test)
==3818==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==3818== 
==3818== 
==3818== HEAP SUMMARY:
==3818==     in use at exit: 153,414 bytes in 2,791 blocks
==3818==   total heap usage: 16,476 allocs, 13,685 frees, 2,331,667 bytes allocated
==3818== 
==3818== LEAK SUMMARY:
==3818==    definitely lost: 18 bytes in 3 blocks
==3818==    indirectly lost: 104 bytes in 4 blocks
==3818==      possibly lost: 34,101 bytes in 1,355 blocks
==3818==    still reachable: 119,191 bytes in 1,429 blocks
==3818==         suppressed: 0 bytes in 0 blocks
==3818== Rerun with --leak-check=full to see details of leaked memory
==3818== 
==3818== For counts of detected and suppressed errors, rerun with: -v
==3818== Use --track-origins=yes to see where uninitialised values come from
==3818== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 187 from 14)
Segmentation fault

Posted: **Mon Apr 26, 2010 10:31 pm**

I can't exactly say what's going on, but it DOES point you roughly to where the error probably is.

==3818== Conditional jump or move depends on uninitialised value(s)
==3818== at 0x409B92C: ??? (in /usr/lib/libSDL-1.2.so.0.11.2)
==3818== by 0x4074355: ??? (in /usr/lib/libSDL-1.2.so.0.11.2)
==3818== by 0x4046965: SDL_InitSubSystem (in /usr/lib/libSDL-1.2.so.0.11.2)
==3818== by 0x4046A36: SDL_Init (in /usr/lib/libSDL-1.2.so.0.11.2)
==3818== by 0x8048DC5: engine::init() (in /home/pythip/Desktop/engine/anim/test)
==3818== by 0x80497E8: main (in /home/pythip/Desktop/engine/anim/test)

==3818== at 0x40FB3F8: TTF_SizeUNICODE (in /usr/lib/libSDL_ttf-2.0.so.0.6.3)
==3818== by 0x40FC3BE: TTF_RenderUNICODE_Solid (in /usr/lib/libSDL_ttf-2.0.so.0.6.3)
==3818== by 0x40FC84F: TTF_RenderText_Solid (in /usr/lib/libSDL_ttf-2.0.so.0.6.3)
==3818== by 0x804912D: graphics::load_files() (in /home/pythip/Desktop/engine/anim/test)
==3818== by 0x804980C: main (in /home/pythip/Desktop/engine/anim/test)

The error appears to be at either
main() engine::init() sdl_init() sdl_inisubsystem()
or
main() graphics::loadfiles() TFF loading.

Usually the location is enough to find out what's going on by simply looking at the code.

Address 0x0 is not stack'd, malloc'd or (recently) free'd

My c++ kung-fu is not powerful enough to know what's going on, but it's safe to assume that Address 0x0 is really 0x00000.... etc. As such, it's possibly a null pointer causing this. So I'd pay close attention to your pointers.

I don't know what debugger you are using, but if you can do step-by-step debugging you can usually find out where the error is pretty easily, albeit slowly.

Posted: **Tue Apr 27, 2010 5:46 am**

Live-Dimension wrote:
Address 0x0 is not stack'd, malloc'd or (recently) free'd
My c++ kung-fu is not powerful enough to know what's going on, but it's safe to assume that Address 0x0 is really 0x00000.... etc. As such, it's possibly a null pointer causing this. So I'd pay close attention to your pointers.

I don't know what debugger you are using, but if you can do step-by-step debugging you can usually find out where the error is pretty easily, albeit slowly.

it is definitely a dereference of a NULL pointer (either freeing it or trying to read from it), so make sure that you aren't trying to read data that's pointed to by a NULL pointer.

Posted: **Tue Apr 27, 2010 7:39 am**

Thanks for the help, I was calling a null pointer.

Posted: **Wed Apr 28, 2010 4:09 pm**

I tell you huhwhat, I had a lot of trouble with that earlier when I was working on my program... I had a pointer, then I put in the pointer again with a slightly different name, and forgot to take out the old pointer and made the references to the old one instead of the new one, and it took me FOREVER to figure out what the hell was wrong....

Posted: **Wed Apr 28, 2010 4:23 pm**

eatcomics wrote:I tell you huhwhat, I had a lot of trouble with that earlier when I was working on my program... I had a pointer, then I put in the pointer again with a slightly different name, and forgot to take out the old pointer and made the references to the old one instead of the new one, and it took me FOREVER to figure out what the hell was wrong....

yes... pointers are evil when it comes to debugging.
Though god knows that they're useful.

Posted: **Wed Apr 28, 2010 4:25 pm**

definitely

Elysian Shadows

How do I interpret the output of a debugger?

How do I interpret the output of a debugger?

Re: How do I interpret the output of a debugger?

Re: How do I interpret the output of a debugger?

Re: How do I interpret the output of a debugger?

Re: How do I interpret the output of a debugger?

Re: How do I interpret the output of a debugger?

Re: How do I interpret the output of a debugger?