DrawCircle causes SIGSEGV

...and here is that other thread. I have a minimal standalone application that creates nothing from config. The only thing added is
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.

Could that be because gdb doesn't know where to find the source that contains glDrawArrays and just runs through the program without stepping in assembler instead?

The really tricky thing with this bug is that it seems to corrupt the call stack with feels a little bit out of my scope for the moment but I'm working on 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"
Cannot access memory at address 0x42c80004
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...

I guess that even if all this is my fault it is not a very polite way to fail in... ;)

Comments

  • edited February 2012
    Mmh, interesting.
    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.
  • edited February 2012
    Also, test set ShowProfiler to true and try it on a object with not graphic for a little Easter egg. :)
  • edited February 2012
    What do you mean by "try it on a object with not graphic"?
    That you have nothing in your world beside an empty object?
  • edited February 2012
    No it should have a body... and maybe everything else, doesn't think that mater as long as it has no graphic.
  • edited February 2012
    Mmh, so I tried with an object with no graphics + profiler and I don't see my Easter egg. Maybe it's because I'm a couple of months early on that one.

    Here's what I get:

    profiler.png
  • edited February 2012
    So I tried to repro your crash on my linuxbox with no luck. For info, I run a 64b linux mint 11 under virtual box, with 3D acceleration support.

    Would you mind sending me an archive with your test, including src+config AND binaries, just for comparison sake?
  • edited February 2012
    Well, something seems very strange but you will find the project in a working state. If it behave the same for you as for me commenting out the Player.Graphic in Player.ini will give
    <ASSERT> (orxDisplay_GLFW_DrawCircle() - include/../plugins/Display/GLFW/orxDisplay.c:1286) [Assertion failed] : <_fRadius >= orxFLOAT_0>
    
    so if you then go on and comment out PlayerBodyBodyPart.Radius it will raise the same SIGSEGV but this time the problematic memory address is set to 0x43960004 instead of 0x42c80004. The first SIGSEGV I talked about should arive if you comment out the line 30 in StandAlone.cpp (orxDisplay_DrawLine).

    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
  • edited February 2012
    [strike]All I need now is an access to it. ;)[/strike]

    Nevermind, I didn't refresh the page after your edit. :)

    I'll have a look tonight.
  • edited February 2012
    I finally got the opportunity to test your project 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).
  • edited February 2012
    If nothing else it would probably have been quite some time before I thought about BackgroundColor. =)

    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.
  • edited February 2012
    Hehe, the BackgroundColor issue sure was sneaky!
    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!
Sign In or Register to comment.