It looks like you're new here. If you want to get involved, click one of these buttons!
orxEvent_AddHandler( orxEVENT_TYPE_RENDER , StandAlone::RenderEventHandler );
and
orxSTATUS orxFASTCALL StandAlone::RenderEventHandler( const orxEVENT* currentEvent )
{
switch (currentEvent->eID)
{
case orxRENDER_EVENT_START:
orxVECTOR dotPosition;
orxVector_Set( &dotPosition, 100, 100, 0 );
orxSTATUS status = orxDisplay_DrawCircle( &dotPosition, orxFLOAT(100), orx2RGBA(0xFF, 0x00, 0x00, 0xFF), orxTRUE );
break;
}
return orxSTATUS_SUCCESS;
}
I'm very new to debugging using gdb mainly via codelite. This SIGSEGV is somewhat illusive... it will always happen after orxDisplay_DrawCircle, if I step into it and go line for line there is a loop where I might try to set a breakpoint after and then press continue. This might or might not raise the SIGSEGV, more often than not but at this point something else happens, probably unrelated to the first issue, my spotify client starts to get intermingled with the current debugging process not in a completly clear way but it will stop and start at random when I step in the source or press continue and so on, also if spotify is lagging it might cause my orxapp to halt. The only thing I can think of is a terrible bug in the alsa somewhere. However... after the loop I step into orxDisplay_GLFW_DrawPrimitive and it is the same here, that it will work if I carefully step over everything but if I apparently recklessly set a breakpoint a few lines further down the source it is a hight risk that it will raise the SIGSEGV. Anyway in the end I come to glDrawArrays where it allays will raise the SIGSEGV when I try to step into it.Program Received signal SIGSEGV
DEBUG>>00002746-stack-list-frames
DEBUG>>00002747-stack-info-frame
DEBUG>>00002748-break-list
DEBUG>>00002746^error,msg="Cannot access memory at address 0x42c80004"
Cannot access memory at address 0x42c80004
DEBUG>>00002747^done,frame={level="0",addr="0x025beda7",func="??"}
DEBUG>>00002749-stack-list-frames
DEBUG>>00002748^done,BreakpointTable={nr_rows="3",nr_cols="6",hdr=[{width="7",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0804bceb",func="StandAlone::RenderEventHandler(__orxEVENT_t const*)",file="/home/andreas/src/TestBed/Klaenk/StandAlone.cpp",fullname="/home/andreas/src/TestBed/Klaenk/StandAlone.cpp",line="25",times="1",original-location="none"/home/andreas/src/TestBed/Klaenk/StandAlone.cpp:25"},bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="none"/home/andreas/src/orx/code/plugins/Display/GLFW/orxDisplay.c:1020",times="0",original-location="none"/home/andreas/src/orx/code/plugins/Display/GLFW/orxDisplay.c:1020"},bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="none"/home/andreas/src/orx/code/plugins/Display/GLFW/orxDisplay.c:1303",times="0",original-location="none"/home/andreas/src/orx/code/plugins/Display/GLFW/orxDisplay.c:1303"}]}
DEBUG>>00002749^error,msg="Cannot access memory at address 0x42c80004"
Cannot access memory at address 0x42c80004
DEBUG>>00002750-var-create - @ "glDrawArrays"
DEBUG>>00002750^done,name="var1",numchild="0",value="{<text variable, no debug info>} 0x6e26a0 <glDrawArrays>",type="<text variable, no debug info>",has_more="0"
DEBUG>>00002751-var-delete "var1"
DEBUG>>00002751^done,ndeleted="1"
seems to be very relevant, it is also the same every time the program run... might that address be inside spotify's memory or maybe alsas or something...Cannot access memory at address 0x42c80004
Comments
I remember that you already had a weird issue with a stack allocated vector when you were doing your own debug rendering.
When you weren't initializing your vector, things were not working.
I'll try to check that tonight. I haven't tried the primitive draw calls on my linux box to be fair, so it's likely that I overlooked something.
I'll let you know what I find.
That you have nothing in your world beside an empty object?
Here's what I get:
Would you mind sending me an archive with your test, including src+config AND binaries, just for comparison sake?
Current system is...
Linux elliot 3.0.0-12-generic #19 SMP Fri Sep 30 16:08:17 CDT 2011 i686 GNU/Linux
gcc version 4.4.3
I'm running Bodhi Linux 1.3 witch is based upon Ubuntu 10.04 (Lucid)
PS. I have removed TestBed.tags from the workspace becouse of size consideration but I guess that is ctags search database anyway. DS. https://forum.orx-project.org/uploads/legacy/fbfiles/files/TestBed.tgz
Nevermind, I didn't refresh the page after your edit.
I'll have a look tonight.
The first difference I saw is that your compiled exe is a 32b whereas mine is a 64b.
Also, as I don't have liborxd.so in my LD_LIBRARY_PATH, I added -Wl,-rpath ./ to the linker command line so that it'll pick liborxd.so from the working directory.
I also modified the include&lib paths to point to my version of orx (latest SVN).
Then I compiled and launched. I get the same assert as you which is normal as there's no graphic hence no size for the bodypart. After the assert all bets are off anyway.
So I restarted again with both a valid graphic or no graphic but a radius to the bodypart and I got my physics debug circle + transform axes.
So I decided to completely remove the physics rendering and see what would happen with your segment drawn in the viewport event handler.
I commented out the graphic and body (hence getting an "empty" object) and got a black screen.
Ah yes, normal, you're asking orx to clean the viewport (BackgroundColor in config). As the cleaning happens after orxRENDER_EVENT_START is handled, the segment would get erased.
So I removed the BackgroundColor property of the viewport and ta-daa, I get a red diagonal segment on screen.
I also did a last try: I changed the event handled from orxRENDER_TYPE_START to orxRENDER_TYPE_STOP so that the segment would get rendered last. And it worked, segment was still displayed.
Last thing: I re-added graphic+body to the object, and ended up having a diagonal red segment on screen, a bitmap for the object and a half transparent circle on top of that object.
As expected.
Never got a SIGSEV unfortunately.
So my question is: are you sure you're not mixing 32b and 64b exe/libraries? Or maybe not using the same version of liborxd.so at link time than at runtime?
Beside those I can't think of much else. Maybe update your OpenGL drivers? (Probably mesa).
I'm sure I didn't mix 32b and 64b since there is no trace of 64b on my computer either in software or hardware, I'm also sure I used the same version of liborxd so that leaves outdated mesa drivers. I think that is very possible since Bodhi currently is based on ubuntu long term support. But that is also a bit strange since even if the mesa lib is old it is supposed to be very stable.
Anyway I realized that I could of course not step into the mesa source since it was not compiled with debug and the small detail of not having the source to begin with might also be a factor.
My very straight forward solution to the problem was to reinstall my system and choose Gentoo instead, and at the same time I installed a hardened version on my local server... so the last couple of days I optimized my computers im absurdum, so right now I'm in the process of setting up my orx development in a autoconf environment only using vim, the console and xmonad as the windows manager.
I guess if the problem still persist the next thing to suspect is hardware failure but at least now I can recompile the entire system in debug mode if necessary.
Thank you for the support even if I think this became a dead end, hopefully.
If you want to be sure your primitive draw calls will always be displayed, you can to them when handling the orxRENDER_EVENT_STOP instead. (There are also events for viewports rendering, btw.)
Mmh, I don't think I checked the 32b version, I'll check that tomorrow night, just in case, but hopefully everything will work just fine on your gentoo.
Let me know!