Crash in portland storage with SKY_FPV

[Vegar]

Standing near the door in PL storage, moving the camera upwards/downwards around a certain angle, looking northeast, it crashes. Neither gdb nor valgrind gives any useful output. This is 100% reproducible, using latest CVS.

 

I can't reproduce this without SKY_FPV, so I assume that's related.

 

No framebuffer enabled, no shaders, no animation programs.

 

gdb output:

map(26):./maps/map6nf_insides.elm

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6cf46e0 (LWP 17065)]
0xb7f6996e in ?? ()
(gdb) bt
#0  0xb7f6996e in ?? ()
#1  0x00000000 in ?? ()

valgrind:

map(26):./maps/map6nf_insides.elm
==17091== 
==17091== Conditional jump or move depends on uninitialised value(s)
==17091==	at 0x82057EE: update_selection(unsigned char*) (select.cpp:101)
==17091==	by 0x820632B: reset_under_the_mouse (select.cpp:383)
==17091==	by 0x80A50C8: display_game_handler (gamewin.c:1025)
==17091==	by 0x8096C40: draw_window (elwindows.c:1166)
==17091==	by 0x80972AF: display_window (elwindows.c:1337)
==17091==	by 0x80940FA: display_windows (elwindows.c:73)
==17091==	by 0x808BF22: draw_scene (draw_scene.c:147)
==17091==	by 0x80CAB88: start_rendering (main.c:180)
==17091==	by 0x80CAF3B: main (main.c:313)
==17091== 
==17091== Conditional jump or move depends on uninitialised value(s)
==17091==	at 0x820580E: update_selection(unsigned char*) (select.cpp:101)
==17091==	by 0x820632B: reset_under_the_mouse (select.cpp:383)
==17091==	by 0x80A50C8: display_game_handler (gamewin.c:1025)
==17091==	by 0x8096C40: draw_window (elwindows.c:1166)
==17091==	by 0x80972AF: display_window (elwindows.c:1337)
==17091==	by 0x80940FA: display_windows (elwindows.c:73)
==17091==	by 0x808BF22: draw_scene (draw_scene.c:147)
==17091==	by 0x80CAB88: start_rendering (main.c:180)
==17091==	by 0x80CAF3B: main (main.c:313)
==17091== 
==17091== Conditional jump or move depends on uninitialised value(s)
==17091==	at 0x8205828: update_selection(unsigned char*) (select.cpp:101)
==17091==	by 0x820632B: reset_under_the_mouse (select.cpp:383)
==17091==	by 0x80A50C8: display_game_handler (gamewin.c:1025)
==17091==	by 0x8096C40: draw_window (elwindows.c:1166)
==17091==	by 0x80972AF: display_window (elwindows.c:1337)
==17091==	by 0x80940FA: display_windows (elwindows.c:73)
==17091==	by 0x808BF22: draw_scene (draw_scene.c:147)
==17091==	by 0x80CAB88: start_rendering (main.c:180)
==17091==	by 0x80CAF3B: main (main.c:313)
==17091== 
----------- The following leads to the crash, I don't know if the above is related. -----------
==17091== Invalid read of size 4
==17091==	at 0x402856E: ???
==17091==	by 0x4E73E01: (within /usr/lib/libGLcore.so.96.43.01)
==17091==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==17091== 
==17091== Process terminating with default action of signal 11 (SIGSEGV)
==17091==  Access not within mapped region at address 0x0
==17091==	at 0x402856E: ???
==17091==	by 0x4E73E01: (within /usr/lib/libGLcore.so.96.43.01)
==17091==

 

Here's a screenshot taken after the crash

Edit: typo

Edited April 5, 2008 by Vegar

[Vegar]

Schmurk suggested to disable CLUSTER_INSIDES, which fixed the crash.

 

Now I see that at the same angle as the client would crash, the map background turns blue, like when water tiles enter the frustum.

 

Edit: Update: Commenting the CLUSTER_INSIDES code in reflection.c seems to fix the crash. I'll dig further into it.

Edited April 6, 2008 by Vegar

[Roja]

I went there but I didn't get any crashes, and I am using cluster insides(i also have debug on).

It's probably related to the problems ppl have with clusters, even without the sky..for some it crashes.

[Schmurk]

Yes and maybe it depends on the distance you use for near/far clip planes.

Now they are different with and without the sky so it's maybe why you have a crash with the sky.

So maybe ppl who crash have a near clip plane value that causes the problem...

[Vegar]

Yes, this seems to be the source of the problems people have reported with cluster insides enabled. In portland storage it's the water tiles from the potion school that's causing the crash. Maybe someone that know the reflections a bit better than me can look further into it, as I'll most likely be busy all next week.

[Vegar]

Bump.

 

Maybe we should get this fixed now that the sky client is out, a lot of people are reporting this crash with it. (Or at least disable clustering for water tiles for now).

[bluap]

Yes, this seems to be the source of the problems people have reported with cluster insides enabled. In portland storage it's the water tiles from the potion school that's causing the crash. Maybe someone that know the reflections a bit better than me can look further into it, as I'll most likely be busy all next week.

Could this be related to this bug. You have a Nvidia T4200 graphics card I seem to remember, when I had this problem, that's what I was using and no-one else could reproduce the problem. May be it was not fixed under all circumstances.

[Schmurk]

I've just read the other thread and it's really interesting. I definitively think that it's an OpenGL error that causes some cards to crash and not others. So we should try to locate the crash and add some OpenGL checks to see if some values are wrong...

I'll try to have a look later.

 

EDIT: I've just committed a fix and it was still the same problem as the one spotted in the other thread. It seems that the code has changed quite a bit since the last thread and the checks for water_buffer_usage value have disappeared. I've added them again after each call of build_water_buffer() and don't have opengl errors anymore so I hope it's fixed...

Edited April 21, 2008 by Schmurk

[Vegar]

Yes! Nice one, Schmurk. It seems to be fixed now. At least I don't get the crashes anymore.

 

Now we just have to fix that that blue background also mentioned in that other thread. Do we really need that on inside maps (dungeon=1)? (maybe this deserves its own thread)

[Schmurk]

My fix does worser effects in portland storage now when you enable reflections with frame buffer.

I'm trying to fix it...

 

EDIT: it should be fixed now however I've noticed a big CPU usage when the blue background appears in PL storage. I don't know where it comes from though...

Edited April 21, 2008 by Schmurk