Hi Curt,
disregard the last message, I must have screwed up somewhere...
anyway...here's the bt after the ATI driver errors:
#87344 0x08418821 in ssgVtxTable::draw_geometry (this=0xecd8ba8)
at ssgVtxTable.cxx:635
#87345 0x08417fe9 in ssgVtxTable::draw (this=0xecd8ba8) at
ssgVtxTable.cxx:560
#87346 0x08405a1b in ssgSelector::cull (this=0xebd9bb0, f=0x8dd0020,
m=0xbf8d62ec, test_needed=1) at ssgSelector.cxx:73
#87347 0x0840feea in ssgRangeSelector::cull (this=0xebd9a98, f=0x8dd0020,
m=0xbf8d62ec, test_needed=1) at ssgRangeSelector.cxx:92
#87348 0x0840deb7 in ssgTransform::cull (this=0xebdc4d0, f=0x8dd0020,
m=0x8dcffc8, test_needed=1) at ssgTransform.cxx:83
#87349 0x083f8230 in ssgBranch::cull (this=0xa719b18, f=0x8dd0020,
m=0x8dcffc8, test_needed=1) at ssgBranch.cxx:276
#87350 0x083fa22b in ssgContext::cull (this=0x1bfc, r=0x0)
at ssgContext.cxx:260
#87351 0x083f6102 in ssgCullAndDraw (r=0xa719b18) at ssg.cxx:303
#87352 0x08056ca8 in FGRenderer::update (refresh_camera_settings=true)
at renderer.cxx:673
#87353 0x08054b7d in FGRenderer::update () at renderer.hxx:34
#87354 0x08081cc1 in GLUTdraw () at fg_os.cxx:118
#87355 0xb7f70884 in glutJoystickGetCenter () from /usr/lib/libglut.so.3
#87356 0xb7f74478 in fgEnumWindows () from /usr/lib/libglut.so.3
#87357 0xb7f70d6f in glutMainLoopEvent () from /usr/lib/libglut.so.3
#87358 0xb7f717fe in glutMainLoop () from /usr/lib/libglut.so.3
#87359 0x08051a82 in fgMainInit (argc=2, argv=0xbf8d6934) at main.cxx:1007
#87360 0x08051259 in main (argc=2, argv=0xbf8d6934) at bootstrap.cxx:193
I will try to understand this but like I mentioned before...I'm not
really a graphics programmer.
thanks for the help!
-E
Curtis L. Olson wrote:
> Enrique Vaamonde wrote:
>
>> Hi Erik,
>> I have tried tonight the cvs version and although I'm not suffering the
>> RenderTexture problem (I use ATI's propietary binary driver - latest
>> version 8.19.10), I have found the following error when starting up FG.
>>
>> RenderTexture Error: glXCreateGLXPbufferPtr() failed
>>
>> The program loads fine after that tho', however, I am still experiencing
>> a segmentation fault when flying at night in the default San
>> Francisco area.
>>
>> It only happens at night in this area, it won't happen when flying
>> during the day in SF or when flying at night somewhere else (at least in
>> the other scenery where I fly). When I take off (usually default runway
>> 28R), I'd fly runway heading for some 15 to 30 seconds and then comes
>> the segmentation fault. So far, running the program inside gdb gives
>> little (at least to me), but I am pasting part of the output below, just
>> hoping it can help anyone to track this issue:
>>
>> 0xafc361b3 in __glim_R200TCLDrawArrays ()
>> from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so
>>
>> #0 0xafc361b3 in __glim_R200TCLDrawArrays ()
>> from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so
>> #1 0xafc35a19 in __glim_R200TCLDrawArrays ()
>> from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so
>> #2 0xafc35a19 in __glim_R200TCLDrawArrays ()
>> from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so
>> .
>> .
>> .
>> <and goes on and on>
>>
>> If you or anyone need any information or additional testing please let
>> me know ... I will try to use the open source driver in the next few
>> days to see how it goes for me.
>>
>>
>
> The fact that the crash is inside the ati driver makes me just a
> little suspicious of a driver bug.
>
> What would be possibly useful is to see the lines further along in the
> backtrace so we can see where in the flightgear/simgear code the crash
> happen.
>
> Thanks,
>
> Curt.
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
