View Issue Details

IDProjectCategoryView StatusLast Update
0003130FSSCPbeamspublic2022-06-11 02:13
ReporterGoober5000 Assigned ToFSO 4  
PrioritynormalSeveritymajorReproducibilitysometimes
Status closedResolutionunable to reproduce 
Product Version3.7.2 RC4 
Summary0003130: The insidious beam crash bug
DescriptionI suddenly started experiencing it myself and now I've noticed some common features. All of the following seem to be necessary:

1) A recent build (latest trunk as of r11178 will do it)
2) A beam begins firing
3) The player is using an NVIDIA card

It occurs on both release and debug builds but NOT when a debug build is run through MSVC 2005, at least. It happens both with and without the 2014 mediaVPs. I've attached a couple of fso_open.log files.

I didn't initially experience this crash when playing through the FS2 campaign on MediaVPs 2014, but then I realized I was playing using the integrated graphics card. As soon as I switched to NVIDIA, the crashes started reliably happening.

This is a show-stopper for the 3.7.2 release as far as I'm concerned.
Additional InformationThreads where the crash has been reported:

http://www.hard-light.net/forums/index.php?topic=88649.0
http://www.hard-light.net/forums/index.php?topic=88662.0
http://www.hard-light.net/forums/index.php?topic=88654.0
TagsNo tags attached.

Relationships

related to 0000001 resolvedtaylor CTD With "Target In Reticle" 

Activities

Goober5000

2014-11-22 00:15

administrator  

fs2_open-mediavps.log (47,382 bytes)

Goober5000

2014-11-22 00:16

administrator  

fs2_open-nomediavps.log (43,030 bytes)

MageKing17

2014-11-22 01:20

developer   ~0016390

The second thread linked doesn't fit the pattern because TheHound's logs show him using an Intel HD 4000, not an nVidia card. I think you're also the first person to report that the crash still occurs with a debug build... if running the debug build through Visual Studio fails to reproduce the problem, have you tried attaching the debugger to a release build?

Goober5000

2014-11-22 18:20

administrator   ~0016391

Last edited: 2014-11-22 18:22

Tried that today. It refuses to crash in MSVC whether it's through release or debug.

But since the crash does occur in a debug build, it should be possible to narrow down the problem by use of logging statements. The cause seems to be in the shader system, because the debug log contains shader information immediately prior to the crash, both with and without MVPs.

If someone wants to heavily instrument the shader system with logging statements and provide me a patch, I'd be happy to run tests.

Goober5000

2014-11-22 18:31

administrator   ~0016392

Actually, let me modify that comment. It doesn't crash if I launch the process from MSVC, but it does crash if I launch the process separately and then attach the debugger.

The crash occurs in opengl_texture_state::Enable, inside the glBindTexture function. The actual source of the crash is in the nvoglv32.dll, for which we don't have the debug symbols. I'm attaching a screenshot of the error as well as the call stack.

Goober5000

2014-11-22 18:31

administrator  

crash error.jpg (15,660 bytes)   
crash error.jpg (15,660 bytes)   

Goober5000

2014-11-22 18:31

administrator  

call stack.txt (6,326 bytes)   
 	nvoglv32.dll!59a64592() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]	
 	nvoglv32.dll!59a78be7() 	
 	nvoglv32.dll!599e6d7e() 	
 	nvoglv32.dll!599da514() 	
 	nvoglv32.dll!599db407() 	
 	nvoglv32.dll!599d3eae() 	
 	nvoglv32.dll!59a67800() 	
>	fs2_open_3_7_1.exe!opengl_texture_state::Enable(unsigned int tex_id=0)  Line 222	C++
 	fs2_open_3_7_1.exe!gr_opengl_tcache_set_internal(int bitmap_handle=0, int bitmap_type=0, float * u_scale=0x0018f94c, float * v_scale=0x0018f948, int tex_unit=0)  Line 1067	C++
 	fs2_open_3_7_1.exe!opengl_aabitmap_ex_internal(int x=880, int y=624, int w=81, int h=15, int sx=0, int sy=0, int resize_mode=1, bool mirror=false)  Line 80 + 0x34 bytes	C++
 	fs2_open_3_7_1.exe!gr_opengl_aabitmap(int x=1024, int y=5000016, int resize_mode=0, bool mirror=false)  Line 306 + 0x1f bytes	C++
 	fs2_open_3_7_1.exe!HudGauge::renderBitmap(int x=880, int y=624)  Line 849 + 0x21 bytes	C++
 	fs2_open_3_7_1.exe!HudGaugeKills::render(float frametime=0.016998291)  Line 2469	C++
 	fs2_open_3_7_1.exe!hud_render_gauges(int cockpit_display_num=-1)  Line 1847 + 0x14 bytes	C++
 	fs2_open_3_7_1.exe!hud_render_all()  Line 1770 + 0x7 bytes	C++
 	fs2_open_3_7_1.exe!game_render_hud(camid cid={...})  Line 4265	C++
 	fs2_open_3_7_1.exe!game_frame(bool paused=false)  Line 4534 + 0xb bytes	C++
 	fs2_open_3_7_1.exe!game_do_frame()  Line 4903 + 0x7 bytes	C++
 	fs2_open_3_7_1.exe!game_do_state(int state=0)  Line 6817	C++
 	fs2_open_3_7_1.exe!gameseq_process_events()  Line 412	C++
 	fs2_open_3_7_1.exe!game_main(char * cmdline=)  Line 7154	C++
 	fs2_open_3_7_1.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x01c95214, int nCmdShow=10)  Line 7222 + 0xd bytes	C++
 	fs2_open_3_7_1.exe!__tmainCRTStartup()  Line 324 + 0x1c bytes	C
 	kernel32.dll!76db338a() 	
 	ntdll.dll!77519f72() 	
 	ntdll.dll!77519f45() 	
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x00700079, int * final_size=0x003d0065, void * header=0x00770022, sound_info * si=0x00000000, int flags=7209065)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!herm_spline::herm_render(int divs=7536759, color * clc=0x00000000)  Line 271 + 0x78 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x006f0064, int * final_size=0x00730077, void * header=0x0067002e, sound_info * si=0x00000000, int flags=6881380)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x006f0064, int * final_size=0x00730077, void * header=0x0057005c, sound_info * si=0x00000000, int flags=7209065)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x00530079, int * final_size=0x00750074, void * header=0x00000062, sound_info * si=0x00000000, int flags=108)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!_png_read_IDAT_data()  + 0x4f bytes	C
 	fs2_open_3_7_1.exe!load_gauge_auto_speed(int base_w=7340153, int base_h=3997797, int hud_font=7798818, bool scale_gauge=true, SCP_vector<int> * ship_idx=0x00320033, color * use_clr=0x002c0022)  Line 3940 + 0x8 bytes	C++
 	fs2_open_3_7_1.exe!herm_spline::herm_render(int divs=7536759, color * clc=0x00000000)  Line 271 + 0x78 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x006f0064, int * final_size=0x00730077, void * header=0x0073005c, sound_info * si=0x00000000, int flags=7536761)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x006f0064, int * final_size=0x00730077, void * header=0x0053005c, sound_info * si=0x00000000, int flags=7536761)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x006f0064, int * final_size=0x00730077, void * header=0x0073005c, sound_info * si=0x00000000, int flags=7536761)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x006f0064, int * final_size=0x00730077, void * header=0x0053005c, sound_info * si=0x00000000, int flags=7536761)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x006f0064, int * final_size=0x00730077, void * header=0x0073005c, sound_info * si=0x00000000, int flags=7536761)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x006f0064, int * final_size=0x00730077, void * header=0x0053005c, sound_info * si=0x00000000, int flags=7536761)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x006f0064, int * final_size=0x00730077, void * header=0x0073005c, sound_info * si=0x00000000, int flags=7536761)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x006f0064, int * final_size=0x00730077, void * header=0x0053005c, sound_info * si=0x00000000, int flags=7536761)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x006f0064, int * final_size=0x00730077, void * header=0x0073005c, sound_info * si=0x00000000, int flags=7536761)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x006f0064, int * final_size=0x00730077, void * header=0x0053005c, sound_info * si=0x00000000, int flags=7536761)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x00000000, int * final_size=0x00000014, void * header=0x00000002, sound_info * si=0x00000000, int flags=0)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!emp_randomize_chars(char * str=0x00000000)  Line 614 + 0x5 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x00000000, int * final_size=0x00000014, void * header=0x0000000a, sound_info * si=0x00000000, int flags=0)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!emp_randomize_chars(char * str=0x00000000)  Line 614 + 0x5 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x00000000, int * final_size=0x00000014, void * header=0x0000000a, sound_info * si=0x00000000, int flags=0)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!emp_randomize_chars(char * str=0x00000000)  Line 614 + 0x5 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x006f0064, int * final_size=0x00330077, void * header=0x00000032, sound_info * si=0x00000000, int flags=7274595)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!ds_load_buffer(int * sid=0x00780045, int * final_size=0x00320033, void * header=0x00630000, sound_info * si=0x00000000, int flags=7143535)  Line 742 + 0x38 bytes	C++
 	fs2_open_3_7_1.exe!_png_read_IDAT_data()  + 0x4f bytes	C
call stack.txt (6,326 bytes)   

Goober5000

2014-11-22 19:45

administrator  

MVP 2014 patches.zip (4,112 bytes)

Goober5000

2014-11-22 19:45

administrator   ~0016393

I've uploaded a zip that contains versions of the MVP 2014 tables so that 3.7.0 can run with the MediaVPs 2014. I still get the crash under 3.7.0.

Goober5000

2014-11-22 21:36

administrator   ~0016394

Updating the NVIDIA drivers did not solve the crash.

m_m

2014-11-23 16:24

developer   ~0016395

The call stack shows that the bitmap_handle argument for gr_opengl_tcache_set_internal is 0. If I read bm_get_next_handle() in bmpman.cpp correctly that should never happen.
Is there a mission where this crash happens consistently?

Goober5000

2014-11-23 17:08

administrator   ~0016396

Yeah, if you load up Exodus (SM3-06) the Nebtuu and Abraxis are firing beams at each other at mission start, so the crash happens almost immediately.

m_m

2014-11-23 17:50

developer   ~0016397

I tried running the mission and checking for bitmap_handle==0 in gr_opengl_tcache_set_internal but that condition is apparently never true on my machine.

MageKing17

2014-11-23 18:38

developer   ~0016398

It shouldn't be possible for bitmap_handle to be 0 in gr_opengl_tcache_set_internal() because it's only called through gr_opengl_tcache_set(), which specifically checks if (bitmap_handle <= 0) and returns 0 if it is. For some reason, gr_opengl_tcache_set() is missing from the attached call stack, which doesn't seem like it should be possible.

Goober5000

2014-11-23 19:30

administrator  

call stack 2.txt (2,458 bytes)   
 	nvoglv32.dll!5dc7c87d() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]	
 	nvoglv32.dll!5dc91b1d() 	
 	nvoglv32.dll!5dc639db() 	
 	nvoglv32.dll!5dc7e527() 	
 	nvoglv32.dll!5dc8da35() 	
 	nvoglv32.dll!5dc7e0f2() 	
 	nvoglv32.dll!5db0d7b8() 	
 	nvoglv32.dll!5d31d738() 	
 	nvoglv32.dll!5da883bb() 	
 	nvoglv32.dll!5da71172() 	
 	nvoglv32.dll!5da712ed() 	
 	nvoglv32.dll!5da71119() 	
 	nvoglv32.dll!5da70c61() 	
 	ntdll.dll!774eec62() 	
 	ntdll.dll!774eeba1() 	
 	ntdll.dll!774ee971() 	
 	ntdll.dll!774eedff() 	
 	ntdll.dll!774eef7b() 	
 	ntdll.dll!774eed75() 	
 	ntdll.dll!774ef3df() 	
 	ntdll.dll!774ef442() 	
 	ntdll.dll!7750f02e() 	
 	ntdll.dll!774ef201() 	
 	ntdll.dll!774ef26c() 	
 	ntdll.dll!774efa39() 	
 	ntdll.dll!774fc5a4() 	
 	ntdll.dll!774fc279() 	
 	ntdll.dll!774efa39() 	
 	ntdll.dll!774fc5a4() 	
 	ntdll.dll!774fc279() 	
 	ntdll.dll!774efb16() 	
 	ntdll.dll!774fc279() 	
 	ntdll.dll!774fc4d7() 	
 	ntdll.dll!774ee1b2() 	
 	ntdll.dll!774fc4bc() 	
 	ntdll.dll!774f0199() 	
 	ntdll.dll!774f01db() 	
 	ntdll.dll!774f01db() 	
 	ntdll.dll!774f032a() 	
 	ntdll.dll!774f03a2() 	
 	ntdll.dll!774ee1b2() 	
 	ntdll.dll!774f0378() 	
 	ntdll.dll!77501130() 	
 	ntdll.dll!77501273() 	
 	ntdll.dll!77501320() 	
 	ntdll.dll!775012ff() 	
 	nvoglv32.dll!5da5fa49() 	
 	nvoglv32.dll!5da5f7fd() 	
 	opengl32.dll!6457c79f() 	
 	opengl32.dll!64585e90() 	
 	gdi32.dll!76175c30() 	
>	fs2_open_3_7_1-DEBUG.exe!gr_opengl_flip()  Line 355 + 0xe bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_flip()  Line 1784 + 0x8 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_flip_page_and_time_it()  Line 3976	C++
 	fs2_open_3_7_1-DEBUG.exe!game_frame(bool paused=false)  Line 4600 + 0x12 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_frame()  Line 4903 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_state(int state=2)  Line 6587	C++
 	fs2_open_3_7_1-DEBUG.exe!gameseq_process_events()  Line 409 + 0x14 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_main(char * cmdline=0x02ca523c)  Line 7153 + 0x5 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x02ca523c, int nCmdShow=10)  Line 7222 + 0x9 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!__tmainCRTStartup()  Line 324 + 0x35 bytes	C
 	fs2_open_3_7_1-DEBUG.exe!WinMainCRTStartup()  Line 196	C
 	kernel32.dll!75c8338a() 	
 	ntdll.dll!774f9f72() 	
 	ntdll.dll!774f9f45() 	
call stack 2.txt (2,458 bytes)   

Goober5000

2014-11-23 19:30

administrator  

call stack 3.txt (2,558 bytes)   
 	nvoglv32.dll!5c53c6c2() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]	
 	nvoglv32.dll!5c551f47() 	
 	nvoglv32.dll!5c4bface() 	
 	nvoglv32.dll!5c4b22b4() 	
 	nvoglv32.dll!5c4b31a7() 	
 	nvoglv32.dll!5c4ad7ae() 	
 	nvoglv32.dll!5c53f310() 	
>	fs2_open_3_7_1-DEBUG.exe!opengl_texture_state::Enable(unsigned int tex_id=673)  Line 221 + 0x1f bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set_internal(int bitmap_handle=532715, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int tex_unit=0)  Line 1067	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set(int bitmap_handle=532715, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int stage=0)  Line 1110 + 0x19 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!opengl_aabitmap_ex_internal(int x=880, int y=624, int w=81, int h=15, int sx=0, int sy=0, int resize_mode=1, bool mirror=false)  Line 80 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 306 + 0x31 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 699 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int x=880, int y=624)  Line 853 + 0x17 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int frame=532715, int x=880, int y=624)  Line 862	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGaugeKills::render(float frametime=0.026000977)  Line 2469	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_gauges(int cockpit_display_num=-1)  Line 1847 + 0x35 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_all()  Line 1770 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_render_hud(camid cid={...})  Line 4265	C++
 	fs2_open_3_7_1-DEBUG.exe!game_frame(bool paused=false)  Line 4534 + 0x13 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_frame()  Line 4903 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_state(int state=2)  Line 6587	C++
 	fs2_open_3_7_1-DEBUG.exe!gameseq_process_events()  Line 409 + 0x14 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_main(char * cmdline=0x002a523c)  Line 7153 + 0x5 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x002a523c, int nCmdShow=10)  Line 7222 + 0x9 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!__tmainCRTStartup()  Line 324 + 0x35 bytes	C
 	fs2_open_3_7_1-DEBUG.exe!WinMainCRTStartup()  Line 196	C
 	kernel32.dll!75c8338a() 	
 	ntdll.dll!774f9f72() 	
 	ntdll.dll!774f9f45() 	
call stack 3.txt (2,558 bytes)   

Goober5000

2014-11-23 19:31

administrator  

fs2_open 3.log (48,048 bytes)

Goober5000

2014-11-23 20:15

administrator  

fs2_open 4.log (456,666 bytes)

Goober5000

2014-11-23 20:15

administrator  

call stack 4.txt (2,558 bytes)   
 	nvoglv32.dll!5d03c6c2() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]	
 	nvoglv32.dll!5d051f47() 	
 	nvoglv32.dll!5cfbface() 	
 	nvoglv32.dll!5cfb22b4() 	
 	nvoglv32.dll!5cfb31a7() 	
 	nvoglv32.dll!5cfad7ae() 	
 	nvoglv32.dll!5d03f310() 	
>	fs2_open_3_7_1-DEBUG.exe!opengl_texture_state::Enable(unsigned int tex_id=673)  Line 221 + 0x1f bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set_internal(int bitmap_handle=532715, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int tex_unit=0)  Line 1067	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set(int bitmap_handle=532715, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int stage=0)  Line 1110 + 0x19 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!opengl_aabitmap_ex_internal(int x=880, int y=624, int w=81, int h=15, int sx=0, int sy=0, int resize_mode=1, bool mirror=false)  Line 80 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 306 + 0x31 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 699 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int x=880, int y=624)  Line 853 + 0x17 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int frame=532715, int x=880, int y=624)  Line 862	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGaugeKills::render(float frametime=0.020996094)  Line 2469	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_gauges(int cockpit_display_num=-1)  Line 1847 + 0x35 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_all()  Line 1770 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_render_hud(camid cid={...})  Line 4265	C++
 	fs2_open_3_7_1-DEBUG.exe!game_frame(bool paused=false)  Line 4534 + 0x13 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_frame()  Line 4903 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_state(int state=2)  Line 6587	C++
 	fs2_open_3_7_1-DEBUG.exe!gameseq_process_events()  Line 409 + 0x14 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_main(char * cmdline=0x02c1523c)  Line 7153 + 0x5 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x02c1523c, int nCmdShow=10)  Line 7222 + 0x9 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!__tmainCRTStartup()  Line 324 + 0x35 bytes	C
 	fs2_open_3_7_1-DEBUG.exe!WinMainCRTStartup()  Line 196	C
 	kernel32.dll!75c8338a() 	
 	ntdll.dll!774f9f72() 	
 	ntdll.dll!774f9f45() 	
call stack 4.txt (2,558 bytes)   

Goober5000

2014-11-23 20:15

administrator   ~0016399

More logs attached.

chief1983

2014-12-19 15:03

administrator   ~0016420

Goober, if you're getting crashes with debug, attaching a debugger and snooping around could be very very helpful here. Perhaps in conversation with another dev or something.

Goober5000

2014-12-20 21:29

administrator   ~0016422

I've done that already. See comment #c16392 that I wrote on 11/22. I tracked down the location of the crash and attached several call stacks.

I'm happy to do more collaboration with whoever wants to step up to fix this, but nobody has stepped up yet. And not being a graphics coder, I don't have the expertise to fix this myself.

chief1983

2014-12-20 21:34

administrator   ~0016423

One of our members mentioned that the crash happens only when directly looking at beam sources. Was this something you observed? If not it might be different bugs.

Goober5000

2014-12-20 22:29

administrator   ~0016424

That's an interesting note. Every crash that I saw was when I was looking directly at the beam, but I didn't try looking away from the beam.

I don't think that tells us much though. We already knew it was graphics related, and there's no need to draw the beam if you're not looking at it.

MageKing17

2014-12-20 22:36

developer   ~0016425

Would be interesting to see if it could be linked to a specific part of drawing the beam (e.g. disable particles and see if it still happens); I'm going to try to reproduce this issue on an nVidia computer today and, with luck, get more data (although I'm also pessimistic the data might be "it doesn't happen on that card").

chief1983

2014-12-20 22:53

administrator   ~0016426

Not just the beam itself, but he could look at the beam freely, and not crash until he looked at its origin. People mentioned that boom warmups had been causing it, so personally I hadn't ruled out that we just had a small sample pool and that it was possibly still audio related, although now I'm more willing to rule that out. But if it's only the origin of the beam, it seems to indicate something with the way the warmup or base animation points are being draw, or possibly how beam origin animations are interacting with the surrounding ship model. With the description of your callstack you mentioned earlier, perhaps it has to do with the animation somehow failing to have loaded in the first place, and upon trying to draw it to load it ends up crapping out because it isn't there to draw in the first place? I take it no one has had this happen with retail, so that might imply it has to do with DDS textures and PCX are immune. That or the actual difference between how MVP beam glows and retail beam glows are configured is related.

MageKing17

2014-12-21 00:55

developer   ~0016427

Null result on a GTX 580; sounds like this problem only affects 600-series and later cards.

Goober5000

2014-12-21 02:45

administrator   ~0016428

Mine is a Quadro K2100M, if that helps.

chief1983

2014-12-21 04:23

administrator   ~0016429

That appears to share a chipset with the GTK660, so that would be in line with the findings. And if you're running Quadro drivers it means they're not any more immune to the issue than the Geforce line drivers.

z64555

2015-01-03 21:59

developer   ~0016435

Last edited: 2015-01-03 22:02

Thought I would try to help out, but I could not repro the crash on my machine.

Build Info:
 SVN r11204
 MSVS Debug AVX configuration

Test Mission:
 SM3-06

GPUs:
 Intel 4700-MQ
 Nvidia GeForce 770M (driver 347.09)

Assets:
 Retail
 mediavps_3612
 MediaVPs_2014

Goober5000

2015-01-03 22:04

administrator   ~0016436

If one of the graphics coders is able to do a code review of the section that crashes, that would be helpful even if he can't reproduce the crash on his own machine. Scrutinizing the code may reveal improperly formatted data, a bad API call, a function being called out-of-order, data being accessed after being freed, or any number of things.

Refer to my previous comments and stack traces, particularly this: "The crash occurs in opengl_texture_state::Enable, inside the glBindTexture function."

Goober5000

2015-01-03 22:49

administrator   ~0016437

Last edited: 2015-01-03 22:49

It's definitely HUD related. I loaded up Exodus and immediately toggled the HUD off, and the beams fired without crashing. Then I toggled the HUD back on while the beam was firing, and insta-crash, even before the HUD became visible again.

Goober5000

2015-01-04 02:07

administrator  

call stack 5.txt (2,558 bytes)   
 	nvoglv32.dll!5aae4592() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]	
 	nvoglv32.dll!5aaf8be7() 	
 	nvoglv32.dll!5aa66d7e() 	
 	nvoglv32.dll!5aa5a514() 	
 	nvoglv32.dll!5aa5b407() 	
 	nvoglv32.dll!5aa53eae() 	
 	nvoglv32.dll!5aae7800() 	
>	fs2_open_3_7_1-DEBUG.exe!opengl_texture_state::Enable(unsigned int tex_id=672)  Line 221 + 0x1f bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set_internal(int bitmap_handle=532715, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int tex_unit=0)  Line 1067	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set(int bitmap_handle=532715, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int stage=0)  Line 1110 + 0x19 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!opengl_aabitmap_ex_internal(int x=880, int y=624, int w=81, int h=15, int sx=0, int sy=0, int resize_mode=1, bool mirror=false)  Line 80 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 306 + 0x31 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 699 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int x=880, int y=624)  Line 853 + 0x17 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int frame=532715, int x=880, int y=624)  Line 862	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGaugeKills::render(float frametime=0.020996094)  Line 2469	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_gauges(int cockpit_display_num=-1)  Line 1847 + 0x35 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_all()  Line 1770 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_render_hud(camid cid={...})  Line 4265	C++
 	fs2_open_3_7_1-DEBUG.exe!game_frame(bool paused=false)  Line 4534 + 0x13 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_frame()  Line 4903 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_state(int state=2)  Line 6587	C++
 	fs2_open_3_7_1-DEBUG.exe!gameseq_process_events()  Line 409 + 0x14 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_main(char * cmdline=0x02f4549c)  Line 7153 + 0x5 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x02f4549c, int nCmdShow=10)  Line 7222 + 0x9 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!__tmainCRTStartup()  Line 324 + 0x35 bytes	C
 	fs2_open_3_7_1-DEBUG.exe!WinMainCRTStartup()  Line 196	C
 	kernel32.dll!7540338a() 	
 	ntdll.dll!777c9f72() 	
 	ntdll.dll!777c9f45() 	
call stack 5.txt (2,558 bytes)   

niffiwan

2015-01-04 07:08

developer   ~0016439

Last edited: 2015-01-04 07:08

I notice that the call stacks always show that the Kills Gauge is being rendered, does the crash still occur if just that one gauge is disabled?

Goober5000

2015-01-04 07:38

administrator   ~0016441

If you can whip up a test mission, I'll test it out. I've been using Exodus (sm3-06) and applying various tweaks.

MageKing17

2015-01-04 07:54

developer   ~0016443

Should be as simple as using the in-game options menu and turning it off; hit F2, enter "HUD Config", click on the kills gauge (it's between ETS and CM count), and set it to "off" and see what happens.

(And then, of course, if it doesn't crash, try turning it on while a beam is firing, although at that point I think it'd be a pretty safe bet that it crashes again.)

Goober5000

2015-01-05 05:31

administrator  

call stack 6.txt (2,558 bytes)   
 	nvoglv32.dll!58804592() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]	
 	nvoglv32.dll!58818be7() 	
 	nvoglv32.dll!58786d7e() 	
 	nvoglv32.dll!5877a514() 	
 	nvoglv32.dll!5877b407() 	
 	nvoglv32.dll!58773eae() 	
 	nvoglv32.dll!58807800() 	
>	fs2_open_3_7_1-DEBUG.exe!opengl_texture_state::Enable(unsigned int tex_id=675)  Line 221 + 0x1f bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set_internal(int bitmap_handle=532715, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int tex_unit=0)  Line 1067	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set(int bitmap_handle=532715, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int stage=0)  Line 1110 + 0x19 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!opengl_aabitmap_ex_internal(int x=880, int y=624, int w=81, int h=15, int sx=0, int sy=0, int resize_mode=1, bool mirror=false)  Line 80 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 306 + 0x31 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 699 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int x=880, int y=624)  Line 853 + 0x17 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int frame=532715, int x=880, int y=624)  Line 862	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGaugeKills::render(float frametime=0.015991211)  Line 2469	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_gauges(int cockpit_display_num=-1)  Line 1847 + 0x35 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_all()  Line 1770 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_render_hud(camid cid={...})  Line 4265	C++
 	fs2_open_3_7_1-DEBUG.exe!game_frame(bool paused=false)  Line 4534 + 0x13 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_frame()  Line 4903 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_state(int state=2)  Line 6587	C++
 	fs2_open_3_7_1-DEBUG.exe!gameseq_process_events()  Line 409 + 0x14 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_main(char * cmdline=0x02b9549c)  Line 7153 + 0x5 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x02b9549c, int nCmdShow=10)  Line 7222 + 0x9 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!__tmainCRTStartup()  Line 324 + 0x35 bytes	C
 	fs2_open_3_7_1-DEBUG.exe!WinMainCRTStartup()  Line 196	C
 	kernel32.dll!7540338a() 	
 	ntdll.dll!777c9f72() 	
 	ntdll.dll!777c9f45() 	
call stack 6.txt (2,558 bytes)   

Goober5000

2015-01-05 05:33

administrator   ~0016444

Last edited: 2015-01-05 05:33

Very interesting. That's exactly what happened... starting the mission with the kills gauge disabled prevented the crash, and then re-enabling that gauge while the mission was in progress caused a crash as soon as I hit Accept. New call stack (number 6) attached, but it's pretty much the same as the previous ones.

MageKing17

2015-01-05 07:30

developer  

hud.cpp.patch (1,806 bytes)   
Index: code/hud/hud.cpp
===================================================================
--- code/hud/hud.cpp	(revision 11207)
+++ code/hud/hud.cpp	(working copy)
@@ -151,49 +151,6 @@
 	}
 };
 
-// used to draw the kills gauge
-hud_frames Kills_gauge;
-int Kills_gauge_loaded = 0;
-int Kills_gauge_coords[GR_NUM_RESOLUTIONS][2] = {
-	{ // GR_640
-		497, 361
-	},
-	{ // GR_1024
-		880, 624
-	}
-};
-int Kills_text_coords[GR_NUM_RESOLUTIONS][2] = {
-	{ // GR_640
-		503, 365
-	},
-	{ // GR_1024
-		886, 628
-	}
-};
-
-int Kills_text_val_coords_gr[GR_NUM_RESOLUTIONS][2] = {
-	{ // GR_640
-		615, 365
-	},
-	{ // GR_1024
-		984, 628
-	}
-};
-
-int Kills_text_val_coords[GR_NUM_RESOLUTIONS][2] = {
-	{ // GR_640
-		571, 365
-	},
-	{ // GR_1024
-		954, 628
-	}
-};
-
-char Kills_fname[GR_NUM_RESOLUTIONS][MAX_FILENAME_LEN] = {
-	"kills1",
-	"kills1"
-};
-
 // used to draw the hud support view
 static int Hud_support_view_active;
 static int Hud_support_view_abort;		// active when we need to display abort message
@@ -237,7 +194,6 @@
 int hud_objective_notify_active();
 void hud_subspace_notify_abort();
 void hud_maybe_display_subspace_notify();
-void hud_init_kills_gauge();
 int hud_maybe_render_emp_icon();
 void hud_init_emp_icon();
 
@@ -1223,7 +1179,6 @@
 	hud_init_wingman_status_gauge();
 	hud_init_target_static();
 	hud_init_text_flash_gauge();
-	hud_init_kills_gauge();
 	hud_stop_subspace_notify();
 	hud_stop_objective_notify();
 	hud_target_last_transmit_level_init();
@@ -2572,14 +2527,6 @@
 }
 
 /**
- * @brief Obsolete initializer for the kills gauge. Now superseded by the new HUD code.
- */
-void hud_init_kills_gauge()
-{
-	Kills_gauge_loaded = 1;
-}
-
-/**
  * @brief Called at mission start to init data, and load support view bitmap if required
  */
 void hud_support_view_init()
hud.cpp.patch (1,806 bytes)   

MageKing17

2015-01-05 07:30

developer   ~0016445

Last edited: 2015-01-05 08:32

Well, I've gone all over the HudGaugeKills code and can't find anything unusual about it. I did find one oddity in hud.cpp that shouldn't be causing any problems, but just to be safe, I've attached a patch file that removes some unused things. Could you compile a build with the patch attached and see if it affects the problem? I don't expect it to, but who knows what could be affecting it...

EDIT: Another patch attached that adds some error checking near the problem area.

MageKing17

2015-01-05 08:31

developer  

gropengltexture.cpp.patch (791 bytes)   
Index: code/graphics/gropengltexture.cpp
===================================================================
--- code/graphics/gropengltexture.cpp	(revision 11207)
+++ code/graphics/gropengltexture.cpp	(working copy)
@@ -1060,8 +1060,11 @@
 		*u_scale = t->u_scale;
 		*v_scale = t->v_scale;
 
+		GL_CHECK_FOR_ERRORS("tcache_set_internal() - before SetTarget()");
 		GL_state.Texture.SetTarget(t->texture_target);
+		GL_CHECK_FOR_ERRORS("tcache_set_internal() - between SetTarget() and Enable()");
 		GL_state.Texture.Enable(t->texture_id);
+		GL_CHECK_FOR_ERRORS("tcache_set_internal() - after Enable()");
 
 		if ( (t->wrap_mode != GL_texture_addressing) && (bitmap_type != TCACHE_TYPE_AABITMAP)
 			&& (bitmap_type != TCACHE_TYPE_INTERFACE) && (bitmap_type != TCACHE_TYPE_CUBEMAP) )
gropengltexture.cpp.patch (791 bytes)   

MageKing17

2015-01-07 22:04

developer  

smother_with_error_checking.patch (2,375 bytes)   
Index: code/graphics/gropenglstate.cpp
===================================================================
--- code/graphics/gropenglstate.cpp	(revision 11208)
+++ code/graphics/gropenglstate.cpp	(working copy)
@@ -179,10 +179,14 @@
 void opengl_texture_state::SetTarget(GLenum tex_target)
 {
 	if (units[active_texture_unit].texture_target != tex_target) {
+		GL_CHECK_FOR_ERRORS("opengl_texture_state::Enable() - before Disable()");
 		Disable();
+		GL_CHECK_FOR_ERRORS("opengl_texture_state::Enable() - after Disable()");
 
 		if (units[active_texture_unit].texture_id) {
+			GL_CHECK_FOR_ERRORS("opengl_texture_state::Enable() - before glBindTexture()");
 			glBindTexture(units[active_texture_unit].texture_target, 0);
+			GL_CHECK_FOR_ERRORS("opengl_texture_state::Enable() - after glBindTexture()");
 			units[active_texture_unit].texture_id = 0;
 		}
 
@@ -213,12 +217,16 @@
 	}
 
 	if ( !shader_mode && (active_texture_unit < (uint)GL_supported_texture_units) ) {
+		GL_CHECK_FOR_ERRORS("opengl_texture_state::Enable() - before glEnable()");
 		glEnable( units[active_texture_unit].texture_target );
+		GL_CHECK_FOR_ERRORS("opengl_texture_state::Enable() - after glEnable()");
 		units[active_texture_unit].enabled = GL_TRUE;
 	}
 
 	if (units[active_texture_unit].texture_id != tex_id) {
+		GL_CHECK_FOR_ERRORS("opengl_texture_state::Enable() - before glBindTexture()");
 		glBindTexture(units[active_texture_unit].texture_target, tex_id);
+		GL_CHECK_FOR_ERRORS("opengl_texture_state::Enable() - after glBindTexture()");
 		units[active_texture_unit].texture_id = tex_id;
 	}
 
Index: code/graphics/gropengltexture.cpp
===================================================================
--- code/graphics/gropengltexture.cpp	(revision 11208)
+++ code/graphics/gropengltexture.cpp	(working copy)
@@ -1060,8 +1060,11 @@
 		*u_scale = t->u_scale;
 		*v_scale = t->v_scale;
 
+		GL_CHECK_FOR_ERRORS("tcache_set_internal() - before SetTarget()");
 		GL_state.Texture.SetTarget(t->texture_target);
+		GL_CHECK_FOR_ERRORS("tcache_set_internal() - between SetTarget() and Enable()");
 		GL_state.Texture.Enable(t->texture_id);
+		GL_CHECK_FOR_ERRORS("tcache_set_internal() - after Enable()");
 
 		if ( (t->wrap_mode != GL_texture_addressing) && (bitmap_type != TCACHE_TYPE_AABITMAP)
 			&& (bitmap_type != TCACHE_TYPE_INTERFACE) && (bitmap_type != TCACHE_TYPE_CUBEMAP) )

Goober5000

2015-01-09 15:56

administrator   ~0016448

I haven't had a chance to test the patch yet, but hopefully I can do so this evening.

Goober5000

2015-01-11 03:43

administrator  

call_stack-2015-01-10.txt (2,558 bytes)   
 	nvoglv32.dll!5ea74592() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]	
 	nvoglv32.dll!5ea88be7() 	
 	nvoglv32.dll!5e9f6d7e() 	
 	nvoglv32.dll!5e9ea514() 	
 	nvoglv32.dll!5e9eb407() 	
 	nvoglv32.dll!5e9e3eae() 	
 	nvoglv32.dll!5ea77800() 	
>	fs2_open_3_7_1-DEBUG.exe!opengl_texture_state::Enable(unsigned int tex_id=680)  Line 228 + 0x1f bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set_internal(int bitmap_handle=532715, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int tex_unit=0)  Line 1067	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set(int bitmap_handle=532715, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int stage=0)  Line 1113 + 0x19 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!opengl_aabitmap_ex_internal(int x=880, int y=624, int w=81, int h=15, int sx=0, int sy=0, int resize_mode=1, bool mirror=false)  Line 80 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 306 + 0x31 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 699 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int x=880, int y=624)  Line 853 + 0x17 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int frame=532715, int x=880, int y=624)  Line 862	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGaugeKills::render(float frametime=0.022003174)  Line 2469	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_gauges(int cockpit_display_num=-1)  Line 1847 + 0x35 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_all()  Line 1770 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_render_hud(camid cid={...})  Line 4265	C++
 	fs2_open_3_7_1-DEBUG.exe!game_frame(bool paused=false)  Line 4534 + 0x13 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_frame()  Line 4903 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_state(int state=2)  Line 6587	C++
 	fs2_open_3_7_1-DEBUG.exe!gameseq_process_events()  Line 409 + 0x14 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_main(char * cmdline=0x02f2549c)  Line 7153 + 0x5 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x02f2549c, int nCmdShow=10)  Line 7222 + 0x9 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!__tmainCRTStartup()  Line 324 + 0x35 bytes	C
 	fs2_open_3_7_1-DEBUG.exe!WinMainCRTStartup()  Line 196	C
 	kernel32.dll!76dc338a() 	
 	ntdll.dll!77e29f72() 	
 	ntdll.dll!77e29f45() 	
call_stack-2015-01-10.txt (2,558 bytes)   

Goober5000

2015-01-11 03:43

administrator  

fs2_open-2015-01-10.log (510,630 bytes)

Goober5000

2015-01-11 03:44

administrator   ~0016449

Or the following evening. >.> Crashed again in the same place. New log and stack trace attached.

MageKing17

2015-01-11 03:51

developer   ~0016450

It looks like it didn't trigger any of the new OpenGL error checking. Did you use the smother_with_error_checking.patch or just gropengltexture.cpp.patch?

Goober5000

2015-01-11 22:30

administrator   ~0016451

Just the smother_with_error_checking.patch actually. But I just ran a new build with both patches and it looked like I got the same result.

MageKing17

2015-01-11 22:39

developer   ~0016452

smother_with_error_checking.patch includes gropengltexture.cpp.patch; clearly, whatever is going wrong here isn't throwing any OpenGL errors.

Someone on the forums reported that the problem has gone away since installing the latest nVidia drivers; is there an updated driver for the Quadro K2100M?

chief1983

2015-01-11 22:42

administrator   ~0016453

Looks like it. http://www.nvidia.com/download/driverResults.aspx/80141/en-us 341.21, on December 5.

Goober5000

2015-01-18 02:30

administrator   ~0016454

I installed the driver update. Crash still occurs.

niffiwan

2015-01-29 12:44

developer   ~0016466

Last edited: 2015-01-29 21:33

There seems to have been another driver update recently; it may be worth testing with it?
http://www.nvidia.com/download/driverResults.aspx/81666/en-us

Version: 347.25 WHQL
Release Date: 2015.1.23

Also, do we know if the problem occurs with mediavps_3612? And do we know the earliest release that it occurs on? (pre 3.7.0)

update: info from krevett62
http://www.hard-light.net/forums/index.php?topic=89060.msg1775367#msg1775367

... for me before updating my nvidia drivers, I was crashing when playing with 3.7.2_RC4 and with MVP 2014 or MVP 3.6.12, but no crash occured with retail data and the same exe. Also 3.7.0 with MVP 3.6.12 worked fine at this time.

Goober5000

2015-02-01 07:59

administrator   ~0016467

Updated the driver again. Still crashes.

Inglonias

2015-02-07 17:04

reporter   ~0016475

Last edited: 2015-02-07 17:20

I have this bug, but trying to reproduce it in the debug builds results in the game running just fine. Weird.

Using a GTX 670 with the latest drivers.

EDIT: Reading the other notes reveals that this is not new information. My bad. Any way I can help with just the debug builds and normal builds?

Goober5000

2015-02-07 17:52

administrator   ~0016476

Debug builds will run on the Intel Integrated graphics card unless you specifically set them to run with the NVIDIA card. I think that's why some people have not seen crashes in debug builds.

I think that all the help testers can give has been given. We know where in the code it crashes, we know about an unusual setting that disables the crashes (turning off the HUD gauge), and we know a possible cause (NVIDIA has said this can happen with badly formatted graphics data).

This bug will only be fixed when a group of graphics coders sit down, take a serious look at it, and make a serious attempt to solve it. It's not going to solve itself, and three separate driver updates have not fixed it.

niffiwan

2015-02-08 22:09

developer   ~0016477

Last edited: 2015-02-09 02:22

@Goober5000; have you had a discussion with Nvidia regarding this issue? If you've got more info from them it'd be useful to see the entire conversation, and in particular understand what "badly formatted graphics data" refers to. Maybe there's something wrong with the retail hud kills gauge .ani?

I've also had a look through the hud kills gauge code and can't see any obvious issues (apart from the one that MageKing17 has already identified). Coverity is reporting some uninitialised variables in the HUD code class constructors but I can't see anywhere obvious that these are being *used* uninitialised (i.e. they're being initialised outside the contructors). Regardless I'll see if I can put together a patch that'll fix those issues and we can see if it makes any difference or not.

One other idea I had was to investigate the possibility that (any of) the beam textures were corrupting/overwriting the kills gauge textures. Would it be possible for you to check the contents of BMPMAN (when FSO crashes) at the relevant bmpman index (532715 in most of the stack traces; and it's not exactly an index given the modulo operations involved, the real index is probably 532715%4750 = 715) and maybe extract the data into a file to check if it looks like valid data?

@Inglonias; I think it'd be useful if you could confirm whether you have dual video cards in your system and whether the debug builds are using the Intel card or the Nvidia one.

niffiwan

2015-02-08 22:31

developer   ~0016478

Last edited: 2015-02-09 02:30

more info; Axem is unable to reproduce the issue.

Nvidia 960
Drivers 347.25
Exodus (SM3-06) with mediavps_2014

So maybe the issue only affect 6xx/7xx series cards and their Quadro equivalents?

edit:

DahBlount also can't repro with a 970

Goober5000

2015-02-09 02:04

administrator  

bmpman_entry.txt (1,404 bytes)   
-		bm_bitmaps[257]	{filename=0x01673348 "kills1.ani" signature=11294 palette_checksum=0 ...}	bitmap_entry
+		filename	0x01673348 "kills1.ani"	char [32]
		signature	11294	unsigned int
		palette_checksum	0	unsigned int
		handle	332757	int
		last_used	69068	int
		type	7 '␇'	unsigned char
		comp_type	0	unsigned char
		ref_count	0	char
		dir_type	-1	int
		mem_taken	1215	int
		num_mipmaps	0	int
		preloaded	2 '␂'	unsigned char
		preload_count	1	int
		used_flags	1 '␁'	unsigned char
		load_count	1	int
-		bm	{w=81 h=15 rowsize=81 ...}	bitmap
		w	81	short
		h	15	short
		rowsize	81	short
		bpp	8 '␈'	unsigned char
		true_bpp	8 '␈'	unsigned char
		flags	0	unsigned char
		data	0	unsigned int
+		palette	0x00000000 <Bad Ptr>	unsigned char *
-		info	{ani={...} user={...} }	bm_extra_info
-		ani	{first_frame=257 num_frames=1 keyframe=0 ...}	bm_extra_info::<unnamed-tag>
		first_frame	257	int
		num_frames	1	int
		keyframe	0	int
		fps	30 '␞'	unsigned char
-		eff	{type=0 filename=0x016733ba "" }	bm_extra_info::<unnamed-tag>::<unnamed-tag>
		type	0	unsigned char
+		filename	0x016733ba ""	char [32]
-		user	{data=0x00000101 bpp='' flags=0 }	bm_extra_info::<unnamed-tag>
		data	0x00000101	void *
		bpp	1 '␁'	unsigned char
		flags	0	unsigned char
		used_last_frame	0	unsigned char
		used_this_frame	1 '␁'	unsigned char
		data_size	0	int
		used_count	1	int
bmpman_entry.txt (1,404 bytes)   

Goober5000

2015-02-09 02:04

administrator   ~0016479

Last edited: 2015-02-09 02:05

@niffiwan: I haven't discussed anything with NVIDIA directly. That comment came from a search on the error message which returned this result:

https://devtalk.nvidia.com/default/topic/720651/opengl/access-violation-in-nvoglv32-dll-how-do-i-track-down-the-problem-/
"Access violations during glDrawArrays or glDrawElements are most often due to incorrectly enabled vertex attribute arrays.
Please check your current state of the enabled vertex attributes very carefully. One which is left enabled inadvertently without providing any or enough data will result in these kinds of errors when sourcing data out of bounds during the draw call."

Good call on checking the contents of bmpman. I looked at bm_bitmaps using the bitmap_handle passed to gr_opengl_tcache_set_internal() at the time of the crash, and it corresponded to kills1.ani. I have attached the rest of the entry as a text file to this ticket but I wouldn't know how to extract the graphical data into a file.

MageKing17

2015-02-09 02:27

developer   ~0016480

Except it's not during glDrawArrays() or glDrawElements(), it's during glBindTexture().

Have you tried taking some other ANI file (like, say, time1.ani), copying it to your /data/hud/ folder, renaming it to "kills1.ani", and seeing what happens?

Goober5000

2015-02-09 04:42

administrator   ~0016482

Yes, I know that glBindTexture is a different function, but the same principle could apply. In the first place, it was a very similar error; in the second place, the forum poster may not have exhaustively listed every single potential crash source; and in the third place, checking that your inputs are valid is a good thing to do no matter what API you are using.

Copying and renaming time1.ani to kills1.ani produced exactly the same crash.

niffiwan

2015-02-09 04:52

developer   ~0016483

The odd thing is that there's a heap of other hud gauges rendered in similar fashion. I guess it'll need a more thorough comparison of the exact calls+params used in each case. I'm kinda assuming it's not a stale OGL state issue since then I'd expect it to crash at the next gauge to be rendered when the kills gauge is off.

MageKing17

2015-02-09 05:23

developer   ~0016485

"Copying and renaming time1.ani to kills1.ani produced exactly the same crash."

And you can see the background of the kills gauge changed, thereby ensuring that this copy is being loaded and not being overridden by a higher-priority kills1.ani somewhere else in the file tree? Just want to make sure. It sounds incredibly odd for it to not be working when time1.ani renders just fine for the mission time gauge.

Both gauges render in pretty much exactly the same way; they call setGaugeColor(), then renderBitmap() on the appropriate frame. For HudGaugeKills, this renderBitmap() call is apparently crashing whenever a beam is onscreen. For HudGaugeMissionTime, it isn't. Just about the only difference I can see is in how they behave slightly differently if first_frame is < 0, but that shouldn't be relevant when both have background images (or cause any problems even if they didn't).

Just about the only zany testing change I can think of to make at this point is to rearrange retail_gauges[] to swap HUD_OBJECT_MISSION_TIME and HUD_OBJECT_KILLS, just to see if it still crashes during HudGaugeKills.

Goober5000

2015-02-09 07:22

administrator   ~0016486

Last edited: 2015-02-09 07:23

Swapping HUD_OBJECT_MISSION_TIME and HUD_OBJECT_KILLS now results in a crash in the mission-time HUD gauge (time1.ani), but at the same bitmap handle as the kills gauge in the previous test. This lends support to niffiwan's earlier hypothesis about memory overwrites:

"One other idea I had was to investigate the possibility that (any of) the beam textures were corrupting/overwriting the kills gauge textures."

niffiwan

2015-02-09 10:21

developer   ~0016487

Last edited: 2015-02-09 10:42

OK, so thinking in the same direction, the 1st beams to fire in SM3-06 would be the VSlash on the Nebtuu? Could you try switching out each texture used by the VSlash, one at a time? i.e.

particleexp01
beam-white3
beam-orange2
beam-orange
(I think they're the only VSlash textures that are unique to beams)
(actually, isn't there a beam glow texture loaded somewhere as well?)
(and hopefully I'm looking in the correct tables, there could be a table I've missed in the mediavps_2014 that's overriding the VSlash)

As for what to replace them with; maybe any original retail textures?
ParticleExp01.ani
beam-white3.pcx
beam-orange2.pcx
beam-orange.pcx

The idea is to isolate which texture is the cause of the issue to hopefully narrow down the area of code that needs checking.

In conjunction with this, maybe use a debug_filter.cfg containing the following lines, in order to get some extra info about the texture load process?
+General
+Warning
+Error
+BmpMan
+BmpInfo
+BMP DEBUG
+BmpFastLoad


edit: D'oh! There is, in mv_effects.vp. Maybe disable that single VP as the 1st test?

edit2: I think I've found the correct textures now.
particle_yellow.eff
VasBeam2Core.dds
VasBeam2Glow.dds
VasBeam2GlowHaze.dds
OrangeFade.dds
beamglow6.eff
capflash.eff
exp06.eff
exp04.eff

Maybe try at replacing the .eff files 1st as I recall that EFF loading/handling changed within the last few years. More recently than any DDS changes at least. Disabling MV_Advanced.vp will probably remove a fair few of them.

Goober5000

2015-02-10 03:00

administrator   ~0016494

The test occurs regardless of whether the MediaVPs are active or not. In all of my recent tests, I've been running with just the standard no-mods configuration. So they are already all retail textures.

MageKing17

2015-02-19 01:28

developer   ~0016498

I don't suppose there's some way to find out exactly what section of memory the kills gauge is stored in and then make FSO break whenever that section of memory changes?

Goober5000

2015-02-19 03:00

administrator   ~0016499

It's very possible, and in fact I've tracked down some devious bugs that way. But I would need to know what I should be looking for. Memory changes all the time in perfectly normal ways.

I'll give you an example of one such bug. Remember my gigantic campaign to fix memset/memmove/memcpy in 2013? That was prompted by a crash where a pointer had a null value that had no business being null. I set a breakpoint on that pointer to trigger when its value changed, and then I ran the test mission. Upon reaching the breakpoint, I immediately saw that memset was being used incorrectly.

MageKing17

2015-02-19 18:00

developer   ~0016500

Well, I was thinking that once it's loaded, the bitmap data shouldn't be changing again, so any change to that memory should be incorrect after the initial loading stage.

chief1983

2015-02-19 18:10

administrator   ~0016501

So the difference between this and that example is that in that example, the pointer's value was changing, but here, we're looking to see if the data in the memory the pointer points to is changing? I'm guessing that's harder to set up a watch for? Or at least not the same.

niffiwan

2015-02-20 01:22

developer   ~0016502

I don't think it'll be much different. Set a data watchpoint on this pointer address, i.e.:

&bm_bitmaps[715]->bm->data

From this page I believe you can set the number of bytes to watch from that point on, which should let you watch all the data for that bitmap.
http://stackoverflow.com/questions/621535/what-are-data-breakpoints

To get the number of bytes I think you just need to read the contents of bm_bitmaps[715].data_size (if I'm reading this correctly BMPMAN_DEBUG is always defined in DEBUG builds)

Goober5000

2015-02-21 04:51

administrator   ~0016503

K. I'll give that a try on Saturday.

LotF

2015-02-22 21:03

reporter   ~0016505

No issues with my GeForce GTX 660 Ti (Vendor: MSI, Driver: nvlddmkm 9.18.13.3788 (ForceWare 337.88) / Vista 64bit)

Goober5000

2015-02-23 01:15

administrator   ~0016509

So I set a data watchpoint on bm_bitmaps[257]->bm->data (not 715, because that's exp05_1) and it had the value 0 during the entire run of the executable. Never changed at all, and was still 0 when the crash occurred.

I am attaching the data watch of the bm_bitmaps[257] entry at the time the crash occurred.

Goober5000

2015-02-23 01:16

administrator  

bm_bitmaps watch.txt (1,328 bytes)   
-bm_bitmaps[257]	{filename=0x01673388 "kills1.ani" signature=11336 palette_checksum=0 ...}	bitmap_entry
	+filename	0x01673388 "kills1.ani"	char [32]
	signature	11336	unsigned int
	palette_checksum	0	unsigned int
	handle	332757	int
	last_used	535909	int
	type	7 '␇'	unsigned char
	comp_type	0	unsigned char
	ref_count	0	char
	dir_type	-1	int
	mem_taken	1215	int
	num_mipmaps	0	int
	preloaded	2 '␂'	unsigned char
	preload_count	1	int
	used_flags	1 '␁'	unsigned char
	load_count	1	int
	-bm	{w=81 h=15 rowsize=81 ...}	bitmap
		w	81	short
		h	15	short
		rowsize	81	short
		bpp	8 '␈'	unsigned char
		true_bpp	8 '␈'	unsigned char
		flags	0	unsigned char
		data	0	unsigned int
		+palette	0x00000000 <Bad Ptr>	unsigned char *
	-info	{ani={...} user={...} }	bm_extra_info
		-ani	{first_frame=257 num_frames=1 keyframe=0 ...}	bm_extra_info::<unnamed-tag>
			first_frame	257	int
			num_frames	1	int
			keyframe	0	int
			fps	30 '␞'	unsigned char
		+eff	{type=0 filename=0x016733fa "" }	bm_extra_info::<unnamed-tag>::<unnamed-tag>
		-user	{data=0x00000101 bpp='' flags=0 }	bm_extra_info::<unnamed-tag>
			data	0x00000101	void *
			bpp	1 '␁'	unsigned char
			flags	0	unsigned char
	used_last_frame	0	unsigned char
	used_this_frame	1 '␁'	unsigned char
	data_size	0	int
	used_count	1	int
bm_bitmaps watch.txt (1,328 bytes)   

MageKing17

2015-02-23 03:41

developer   ~0016510

ref_count is 0; that means that entry isn't being drawn at the time the crash is happening. Given the fact that bm->data is 0, this almost certainly means that this bitmap entry has never been drawn.

It's rather odd that this is bm_bitmaps[257] when the bitmap_handle in previous call stacks was 532715 (which, modulo MAX_BITMAPS, should be 715 as niffiwan referenced earlier). This isn't still with HUD_OBJECT_MISSION_TIME and HUD_OBJECT_KILLS swapped in retail_gauges[], is it?

Goober5000

2015-02-23 04:42

administrator   ~0016511

Well, bitmap handles aren't set in stone. Their loading order probably depends on the sequence in which you do things. In recent test runs the bitmap_handle has been 332757, which mod 4750 is 257.

The HUD_OBJECT_MISSION_TIME and HUD_OBJECT_KILLS are not still swapped.

MageKing17

2015-02-27 00:56

developer  

disable_reuse.patch (582 bytes)   
Index: code/graphics/gropengltexture.cpp
===================================================================
--- code/graphics/gropengltexture.cpp	(revision 11258)
+++ code/graphics/gropengltexture.cpp	(working copy)
@@ -998,6 +998,7 @@
 		reload = 0;
 	}
 	// different bitmap altogether - determine if the new one can use the old one's slot
+	/*
 	else if (tslot->bitmap_handle != bitmap_handle) {
 		if ( (final_w == tslot->w) && (final_h == tslot->h) ) {
 			reload = 1;
@@ -1005,6 +1006,7 @@
 			reload = 0;
 		}
 	}
+	*/
 
 	// set the bits per pixel
 	tslot->bpp = bmp->bpp;
disable_reuse.patch (582 bytes)   

MageKing17

2015-02-27 00:57

developer   ~0016515

After stepping through the related graphics code, it would seem that the crash is actually occurring before there's ever a chance to even load the relevant bitmap data; this suggests that the problem isn't related to the graphics data, but is instead related to how OpenGL is being used. As an experiment, I've uploaded a patch that disables a bit of code that causes the engine to re-use a texture slot; if it still crashes with this patch, then I'm out of ideas.

Goober5000

2015-03-02 07:01

administrator   ~0016523

Crashed again, same place. Same bitmap handle, in fact. (Yes, I double-checked that your patch had been applied.)

MageKing17

2015-03-02 07:40

developer   ~0016524

Well, I wouldn't expect the bitmap handle to change; the texture slots I am referring to are the texture IDs generated by glGenTextures(); I had thought that perhaps forcing it to free the IDs and regenerate fresh ones would avoid some wonky driver issue and fix the problem. Since that appears to not be the case... as I previously said, I'm out of ideas.

MageKing17

2015-03-04 03:17

developer   ~0016533

After reading an offhanded comment niffiwan made in the March newsletter ("Maybe we should just reorder the hud gauges array such that an unused/little used HUD gauge is in the (ahem) *slot of doom* and then the workaround is to turn off the gauge"), I've come up with a stupid idea. Latest patch creates a "dummy" HUD gauge that's more-or-less an exact copy of HudGaugeKills, but a render() function that doesn't do anything, and inserts it before HUD_OBJECT_KILLS in retail_gauges[]. Given the behavior regarding swapping HUD_OBJECT_MISSION_TIME and HUD_OBJECT_KILLS, and the fact that turning off the kills gauge makes it not crash, this should theoretically fix the problem (even if it is a dirty, dirty hack).

Goober5000

2015-03-04 05:45

administrator  

call stack wo dummy.txt (2,559 bytes)   
 	nvoglv32.dll!585d1682() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]	
 	nvoglv32.dll!585e81f7() 	
 	nvoglv32.dll!5855a35e() 	
 	nvoglv32.dll!5854c97d() 	
 	nvoglv32.dll!5854d967() 	
 	nvoglv32.dll!5854752e() 	
 	nvoglv32.dll!585d4532() 	
>	fs2_open_3_7_1-DEBUG.exe!opengl_texture_state::Enable(unsigned int tex_id=260)  Line 221 + 0x1f bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set_internal(int bitmap_handle=332757, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int tex_unit=0)  Line 1067	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set(int bitmap_handle=332757, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int stage=0)  Line 1110 + 0x19 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!opengl_aabitmap_ex_internal(int x=880, int y=624, int w=81, int h=15, int sx=0, int sy=0, int resize_mode=1, bool mirror=false)  Line 80 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 306 + 0x31 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 699 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int x=880, int y=624)  Line 853 + 0x17 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int frame=332757, int x=880, int y=624)  Line 862	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGaugeKills::render(float frametime=0.0083312988)  Line 2469	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_gauges(int cockpit_display_num=-1)  Line 1847 + 0x35 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_all()  Line 1770 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_render_hud(camid cid={...})  Line 4265	C++
 	fs2_open_3_7_1-DEBUG.exe!game_frame(bool paused=false)  Line 4534 + 0x13 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_frame()  Line 4903 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_state(int state=2)  Line 6587	C++
 	fs2_open_3_7_1-DEBUG.exe!gameseq_process_events()  Line 409 + 0x14 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_main(char * cmdline=0x02c75344)  Line 7153 + 0x5 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x02c75344, int nCmdShow=10)  Line 7222 + 0x9 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!__tmainCRTStartup()  Line 324 + 0x35 bytes	C
 	fs2_open_3_7_1-DEBUG.exe!WinMainCRTStartup()  Line 196	C
 	kernel32.dll!75e8338a() 	
 	ntdll.dll!77109f72() 	
 	ntdll.dll!77109f45() 	
call stack wo dummy.txt (2,559 bytes)   

Goober5000

2015-03-04 05:45

administrator  

call stack w dummy.txt (2,558 bytes)   
 	nvoglv32.dll!56e01682() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]	
 	nvoglv32.dll!56e181f7() 	
 	nvoglv32.dll!56d8a35e() 	
 	nvoglv32.dll!56d7c97d() 	
 	nvoglv32.dll!56d7d967() 	
 	nvoglv32.dll!56d7752e() 	
 	nvoglv32.dll!56e04532() 	
>	fs2_open_3_7_1-DEBUG.exe!opengl_texture_state::Enable(unsigned int tex_id=260)  Line 221 + 0x1f bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set_internal(int bitmap_handle=332757, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int tex_unit=0)  Line 1067	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set(int bitmap_handle=332757, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int stage=0)  Line 1110 + 0x19 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!opengl_aabitmap_ex_internal(int x=880, int y=624, int w=81, int h=15, int sx=0, int sy=0, int resize_mode=1, bool mirror=false)  Line 80 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 306 + 0x31 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 699 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int x=880, int y=624)  Line 809 + 0x17 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int frame=332757, int x=880, int y=624)  Line 818	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGaugeKills::render(float frametime=0.018997192)  Line 2462	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_gauges(int cockpit_display_num=-1)  Line 1802 + 0x35 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_all()  Line 1725 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_render_hud(camid cid={...})  Line 4265	C++
 	fs2_open_3_7_1-DEBUG.exe!game_frame(bool paused=false)  Line 4534 + 0x13 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_frame()  Line 4903 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_state(int state=2)  Line 6587	C++
 	fs2_open_3_7_1-DEBUG.exe!gameseq_process_events()  Line 409 + 0x14 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_main(char * cmdline=0x02c55344)  Line 7153 + 0x5 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x02c55344, int nCmdShow=10)  Line 7222 + 0x9 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!__tmainCRTStartup()  Line 324 + 0x35 bytes	C
 	fs2_open_3_7_1-DEBUG.exe!WinMainCRTStartup()  Line 196	C
 	kernel32.dll!75e8338a() 	
 	ntdll.dll!77109f72() 	
 	ntdll.dll!77109f45() 	
call stack w dummy.txt (2,558 bytes)   

Goober5000

2015-03-04 05:46

administrator  

call stack w dummy and kills disabled.txt (2,558 bytes)   
 	nvoglv32.dll!585d1682() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]	
 	nvoglv32.dll!585e81f7() 	
 	nvoglv32.dll!5855a35e() 	
 	nvoglv32.dll!5854c97d() 	
 	nvoglv32.dll!5854d967() 	
 	nvoglv32.dll!5854752e() 	
 	nvoglv32.dll!585d4532() 	
>	fs2_open_3_7_1-DEBUG.exe!opengl_texture_state::Enable(unsigned int tex_id=256)  Line 221 + 0x1f bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set_internal(int bitmap_handle=332757, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int tex_unit=0)  Line 1067	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set(int bitmap_handle=332757, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int stage=0)  Line 1110 + 0x19 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!opengl_aabitmap_ex_internal(int x=880, int y=624, int w=81, int h=15, int sx=0, int sy=0, int resize_mode=1, bool mirror=false)  Line 80 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 306 + 0x31 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 699 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int x=880, int y=624)  Line 809 + 0x17 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int frame=332757, int x=880, int y=624)  Line 818	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGaugeKills::render(float frametime=0.032012939)  Line 2462	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_gauges(int cockpit_display_num=-1)  Line 1802 + 0x35 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_all()  Line 1725 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_render_hud(camid cid={...})  Line 4265	C++
 	fs2_open_3_7_1-DEBUG.exe!game_frame(bool paused=false)  Line 4534 + 0x13 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_frame()  Line 4903 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_state(int state=2)  Line 6587	C++
 	fs2_open_3_7_1-DEBUG.exe!gameseq_process_events()  Line 409 + 0x14 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_main(char * cmdline=0x02bf5344)  Line 7153 + 0x5 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x02bf5344, int nCmdShow=10)  Line 7222 + 0x9 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!__tmainCRTStartup()  Line 324 + 0x35 bytes	C
 	fs2_open_3_7_1-DEBUG.exe!WinMainCRTStartup()  Line 196	C
 	kernel32.dll!75e8338a() 	
 	ntdll.dll!77109f72() 	
 	ntdll.dll!77109f45() 	

Goober5000

2015-03-04 05:46

administrator  

different crash call stack.txt (2,453 bytes)   
 	nvoglv32.dll!5798183d() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]	
 	nvoglv32.dll!57997dcd() 	
 	nvoglv32.dll!5796f01b() 	
 	nvoglv32.dll!579836cc() 	
 	nvoglv32.dll!57993c04() 	
 	nvoglv32.dll!57983122() 	
 	nvoglv32.dll!57843b30() 	
 	nvoglv32.dll!56ff330e() 	
 	nvoglv32.dll!577bc367() 	
 	nvoglv32.dll!577a4f52() 	
 	nvoglv32.dll!577a50cd() 	
 	nvoglv32.dll!577a4f06() 	
 	nvoglv32.dll!577a4a91() 	
>	fs2_open_3_7_1-DEBUG.exe!gr_opengl_string(float sx=2.290e-039#DEN, float sy=3.0147235e-037, const char * s=0x02b4388c, int resize_mode=1634004)  Line 537 + 0x21 bytes	C++
 	ntdll.dll!770ffa39() 	
 	ntdll.dll!7710c5a4() 	
 	ntdll.dll!7710c279() 	
 	ntdll.dll!770ffa39() 	
 	ntdll.dll!7710c5a4() 	
 	ntdll.dll!7710c279() 	
 	ntdll.dll!770ffb16() 	
 	ntdll.dll!7710c279() 	
 	ntdll.dll!7710c4d7() 	
 	ntdll.dll!770fe1b2() 	
 	ntdll.dll!7710c4bc() 	
 	ntdll.dll!770fe38c() 	
 	ntdll.dll!770fe38c() 	
 	ntdll.dll!770fe38c() 	
 	ntdll.dll!770fe0f2() 	
 	ntdll.dll!77100199() 	
 	ntdll.dll!771001db() 	
 	kernel32.dll!75e814ad() 	
 	ntdll.dll!771001db() 	
 	ntdll.dll!7710032a() 	
 	ntdll.dll!771003a2() 	
 	ntdll.dll!770fe1b2() 	
 	ntdll.dll!77100378() 	
 	ntdll.dll!77111130() 	
 	ntdll.dll!77111273() 	
 	ntdll.dll!77111320() 	
 	nvoglv32.dll!57792ec2() 	
 	nvoglv32.dll!57792c1d() 	
 	opengl32.dll!5f22c79f() 	
 	opengl32.dll!5f235e90() 	
 	gdi32.dll!75025c30() 	
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_flip()  Line 355 + 0xe bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_flip()  Line 1784 + 0x8 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_flip_page_and_time_it()  Line 3976	C++
 	fs2_open_3_7_1-DEBUG.exe!game_frame(bool paused=false)  Line 4600 + 0x12 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_frame()  Line 4903 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_state(int state=2)  Line 6587	C++
 	fs2_open_3_7_1-DEBUG.exe!gameseq_process_events()  Line 409 + 0x14 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_main(char * cmdline=0x02c95344)  Line 7153 + 0x5 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x02c95344, int nCmdShow=10)  Line 7222 + 0x9 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!__tmainCRTStartup()  Line 324 + 0x35 bytes	C
 	fs2_open_3_7_1-DEBUG.exe!WinMainCRTStartup()  Line 196	C
 	kernel32.dll!75e8338a() 	
 	ntdll.dll!77109f72() 	
 	ntdll.dll!77109f45() 	
different crash call stack.txt (2,453 bytes)   

Goober5000

2015-03-04 05:46

administrator  

Goober5000

2015-03-04 05:47

administrator   ~0016534

Well, this was interesting. With your patch applied, the game still crashes in the same place, with the same bitmap_handle, and using the same kills gauge. Not only that, but disabling the kills gauge in the HUD config doesn't work -- the gauge still appears in the mission and the crash still occurs.

To double-check this, I reverted the patch and ran things again. With the patch reverted, disabling the kills gauge worked and prevented the crash, while leaving the HUD gauge active caused the crash.

I did this series of tests twice. The first time I realized adding the extra HUD gauge might introduce some unknown problem with pilot profiles, so during the second cycle I created a new pilot for each of the trunk build and the patched build. Same result in all respects, including the patched build not actually disabling the kills gauge in-mission when you disable the kills gauge in your settings.

I've uploaded call stacks of the second cycle's series of tests.

(It's worth noting that during the first cycle, with the potentially compromised pilot files, I encountered one crash that was completely different, though it *also* occurred right at the beginning of Exodus. I've uploaded the call stack and log for that one crash as well.)

MageKing17

2015-03-04 06:06

developer  

3130.patch (9,855 bytes)   
Index: code/hud/hud.cpp
===================================================================
--- code/hud/hud.cpp	(revision 11274)
+++ code/hud/hud.cpp	(working copy)
@@ -151,49 +151,6 @@
 	}
 };
 
-// used to draw the kills gauge
-hud_frames Kills_gauge;
-int Kills_gauge_loaded = 0;
-int Kills_gauge_coords[GR_NUM_RESOLUTIONS][2] = {
-	{ // GR_640
-		497, 361
-	},
-	{ // GR_1024
-		880, 624
-	}
-};
-int Kills_text_coords[GR_NUM_RESOLUTIONS][2] = {
-	{ // GR_640
-		503, 365
-	},
-	{ // GR_1024
-		886, 628
-	}
-};
-
-int Kills_text_val_coords_gr[GR_NUM_RESOLUTIONS][2] = {
-	{ // GR_640
-		615, 365
-	},
-	{ // GR_1024
-		984, 628
-	}
-};
-
-int Kills_text_val_coords[GR_NUM_RESOLUTIONS][2] = {
-	{ // GR_640
-		571, 365
-	},
-	{ // GR_1024
-		954, 628
-	}
-};
-
-char Kills_fname[GR_NUM_RESOLUTIONS][MAX_FILENAME_LEN] = {
-	"kills1",
-	"kills1"
-};
-
 // used to draw the hud support view
 static int Hud_support_view_active;
 static int Hud_support_view_abort;		// active when we need to display abort message
@@ -237,7 +194,6 @@
 int hud_objective_notify_active();
 void hud_subspace_notify_abort();
 void hud_maybe_display_subspace_notify();
-void hud_init_kills_gauge();
 int hud_maybe_render_emp_icon();
 void hud_init_emp_icon();
 
@@ -1223,7 +1179,6 @@
 	hud_init_wingman_status_gauge();
 	hud_init_target_static();
 	hud_init_text_flash_gauge();
-	hud_init_kills_gauge();
 	hud_stop_subspace_notify();
 	hud_stop_objective_notify();
 	hud_target_last_transmit_level_init();
@@ -2423,6 +2378,44 @@
 	renderString(fl2i((float)position[0] - ((float)w / 2.0f)), position[1], Hud_text_flash);
 }
 
+HudGaugeDummy::HudGaugeDummy():
+HudGauge(HUD_OBJECT_DUMMY, HUD_DUMMY_GAUGE, false, false, (VM_EXTERNAL | VM_DEAD_VIEW | VM_WARP_CHASE | VM_PADLOCK_ANY | VM_OTHER_SHIP), 255, 255, 255)
+{
+}
+
+void HudGaugeDummy::initBitmaps(const char *fname)
+{
+	Dummy_gauge.first_frame = bm_load_animation(fname, &Dummy_gauge.num_frames);
+	if ( Dummy_gauge.first_frame == -1 ) {
+		Warning(LOCATION, "Could not load in the ani: %s\n", fname);
+	}
+}
+
+void HudGaugeDummy::initTextOffsets(int x, int y)
+{
+	text_offsets[0] = x;
+	text_offsets[1] = y;
+}
+
+void HudGaugeDummy::initTextValueOffsets(int x, int y)
+{
+	text_value_offsets[0] = x;
+	text_value_offsets[1] = y;
+}
+
+void HudGaugeDummy::pageIn()
+{
+	bm_page_in_aabitmap(Dummy_gauge.first_frame, Dummy_gauge.num_frames);
+}
+
+/**
+ * @brief Display absolutely nothing.
+ */
+void HudGaugeDummy::render(float frametime)
+{
+	return;
+}
+
 HudGaugeKills::HudGaugeKills():
 HudGauge(HUD_OBJECT_KILLS, HUD_KILLS_GAUGE, false, false, (VM_EXTERNAL | VM_DEAD_VIEW | VM_WARP_CHASE | VM_PADLOCK_ANY | VM_OTHER_SHIP), 255, 255, 255)
 {
@@ -2572,14 +2565,6 @@
 }
 
 /**
- * @brief Obsolete initializer for the kills gauge. Now superseded by the new HUD code.
- */
-void hud_init_kills_gauge()
-{
-	Kills_gauge_loaded = 1;
-}
-
-/**
  * @brief Called at mission start to init data, and load support view bitmap if required
  */
 void hud_support_view_init()
Index: code/hud/hud.h
===================================================================
--- code/hud/hud.h	(revision 11274)
+++ code/hud/hud.h	(working copy)
@@ -352,6 +352,21 @@
 	int maybeTextFlash();
 };
 
+class HudGaugeDummy: public HudGauge
+{
+	hud_frames Dummy_gauge;
+
+	int text_offsets[2];
+	int text_value_offsets[2];
+public:
+	HudGaugeDummy();
+	void initBitmaps(const char *fname);
+	void initTextOffsets(int x, int y);
+	void initTextValueOffsets(int x, int y);
+	void render(float frametime);
+	void pageIn();
+};
+
 class HudGaugeKills: public HudGauge
 {
 	hud_frames Kills_gauge;
Index: code/hud/hudconfig.cpp
===================================================================
--- code/hud/hudconfig.cpp	(revision 11274)
+++ code/hud/hudconfig.cpp	(working copy)
@@ -87,7 +87,8 @@
 	"warning flash",
 	"comm menu",
 	"support gauge",
-	"lag gauge"
+	"lag gauge",
+	"dummy gauge"
 };
 
 // specify the max distance that the radar should detect objects
@@ -302,6 +303,7 @@
 		HC_gauge_region("HCB_52",	465,	8,		52,	0,	0,	-1, 0,	0),			// comm menu
 		HC_gauge_region("HCB_46",	324,	264,	46,	0,	0,	-1, 0,	0),			// support view gauge
 		HC_gauge_region("HCB_47",	418,	262,	47,	0,	0,	-1, 0,	0),			// netlag icon gauge
+		HC_gauge_region("none",		1,		1,		-1,	0,	0,	-1,	0,	0),			// dummy gauge
 	//XSTR:ON
 	},
 	{ // GR_1024
@@ -345,6 +347,7 @@
 		HC_gauge_region("2_HCB_52",	744,	14,	52,	0,	0,	-1, 0,	0),			// comm menu
 		HC_gauge_region("2_HCB_46",	520,	422,	46,	0,	0,	-1, 0,	0),			// support view gauge
 		HC_gauge_region("2_HCB_47",	670,	419,	47,	0,	0,	-1, 0,	0),			// netlag icon gauge
+		HC_gauge_region("none",		1,		1,		-1,	0,	0,	-1,	0,	0),			// dummy gauge
 	//XSTR:ON
 	}
 };
@@ -440,6 +443,8 @@
 		return XSTR("support gauge", 1461);
 	case 38:
 		return XSTR("lag gauge", 1462);
+	case 39:
+		return XSTR("dummy gauge", -1);
 	}
 	return NULL;
 }
Index: code/hud/hudgauges.h
===================================================================
--- code/hud/hudgauges.h	(revision 11274)
+++ code/hud/hudgauges.h	(working copy)
@@ -13,7 +13,7 @@
 #define __HUD_COMMON_H__
 
 // HUD gauge types
-#define NUM_HUD_GAUGES							39
+#define NUM_HUD_GAUGES							40
 
 #define HUD_LEAD_INDICATOR						0
 #define HUD_ORIENTATION_TEE					1
@@ -54,6 +54,7 @@
 #define HUD_MESSAGE_BOX							36
 #define HUD_SUPPORT_GAUGE						37
 #define HUD_LAG_GAUGE							38
+#define HUD_DUMMY_GAUGE							39
 
 extern char *HUD_gauge_text[NUM_HUD_GAUGES];					// defined in sexp.cpp!!!!
 
Index: code/hud/hudparse.cpp
===================================================================
--- code/hud/hudparse.cpp	(revision 11274)
+++ code/hud/hudparse.cpp	(working copy)
@@ -50,7 +50,7 @@
 int Hud_font = -1;
 
 //WARNING: If you add gauges to this array, make sure to bump num_default_gauges!
-int num_default_gauges = 42;
+int num_default_gauges = 43;
 static int retail_gauges[] = {
 	HUD_OBJECT_MESSAGES,
 	HUD_OBJECT_TRAINING_MESSAGES,
@@ -91,6 +91,7 @@
 	HUD_OBJECT_HOSTILE_TRI,
 	HUD_OBJECT_TARGET_TRI,
 	HUD_OBJECT_MISSILE_TRI,
+	HUD_OBJECT_DUMMY,
 	HUD_OBJECT_KILLS,
 	HUD_OBJECT_FIXED_MESSAGES,
 	HUD_OBJECT_ETS_RETAIL
@@ -144,6 +145,7 @@
 	{ "Hostile direction",	HUD_OBJECT_HOSTILE_TRI,			0},
 	{ "Target direction",	HUD_OBJECT_TARGET_TRI,			0},
 	{ "Missile indicator",	HUD_OBJECT_MISSILE_TRI,			0},
+	{ "Dummy",				HUD_OBJECT_DUMMY,				0},
 	{ "Kills",				HUD_OBJECT_KILLS,				0},
 	{ "Fixed messages",		HUD_OBJECT_FIXED_MESSAGES,		0},
 	{ "Ets retail",			HUD_OBJECT_ETS_RETAIL,			0}
@@ -840,6 +842,9 @@
 	if(optional_string("+Missile Triangles:"))
 		return HUD_OBJECT_MISSILE_TRI;
 
+	if(optional_string("+Dummy:"))
+		return HUD_OBJECT_DUMMY;
+
 	if(optional_string("+Kills:"))
 		return HUD_OBJECT_KILLS;
 
@@ -1021,6 +1026,9 @@
 	case HUD_OBJECT_MISSILE_TRI:
 		load_gauge_missile_tri(base_w, base_h, hud_font, scale_gauge, ship_idx, use_clr);
 		break;
+	case HUD_OBJECT_DUMMY:
+		load_gauge_dummy(base_w, base_h, hud_font, scale_gauge, ship_idx, use_clr);
+		break;
 	case HUD_OBJECT_KILLS:
 		load_gauge_kills(base_w, base_h, hud_font, scale_gauge, ship_idx, use_clr);
 		break;
@@ -5088,6 +5096,60 @@
 	}
 }
 
+void load_gauge_dummy(int base_w, int base_h, int hud_font, bool scale_gauge, SCP_vector<int>* ship_idx, color *use_clr)
+{
+	float origin[2] = {1.0, 1.0};
+	int offset[2];
+	int text_offsets[2] = {6, 4};
+	int text_value_offsets[2] = {74, 4};
+	char fname[MAX_FILENAME_LEN] = "kills1";
+
+	if(gr_screen.res == GR_640) {
+		offset[0] = -143;
+		offset[1] = -119;
+		
+		if(Lcl_gr) {
+			text_value_offsets[0] = 118;
+			text_value_offsets[1] = 4;
+		}
+	} else {
+		offset[0] = -144;
+		offset[1] = -144;
+
+		if(Lcl_gr) {
+			text_value_offsets[0] = 104;
+			text_value_offsets[1] = 4;
+		}
+	}
+
+	HudGaugeDummy* hud_gauge = gauge_load_common<HudGaugeDummy>(base_w, base_h, hud_font, scale_gauge, ship_idx, use_clr, origin[0], origin[1], offset[0], offset[1]);
+
+	if(optional_string("Filename:")) {
+		stuff_string(fname, F_NAME, MAX_FILENAME_LEN);
+	}
+	if(optional_string("Text Offsets:")) {
+		stuff_int_list(text_offsets, 2);
+	}
+	if(optional_string("Value Offsets:")) {
+		stuff_int_list(text_value_offsets, 2);
+	}
+
+	hud_gauge->initBitmaps(fname);
+	hud_gauge->initTextOffsets(text_offsets[0], text_offsets[1]);
+	hud_gauge->initTextValueOffsets(text_value_offsets[0], text_value_offsets[1]);
+
+	if(ship_idx->at(0) >= 0) {
+		for (SCP_vector<int>::iterator ship_index = ship_idx->begin(); ship_index != ship_idx->end(); ++ship_index) {
+			HudGaugeDummy* instance = new HudGaugeDummy();
+			*instance = *hud_gauge;
+			Ship_info[*ship_index].hud_gauges.push_back(instance);
+		}
+		delete hud_gauge;
+	} else {
+		default_hud_gauges.push_back(hud_gauge);
+	}
+}
+
 void load_gauge_kills(int base_w, int base_h, int hud_font, bool scale_gauge, SCP_vector<int>* ship_idx, color *use_clr)
 {
 	float origin[2] = {1.0, 1.0};
Index: code/hud/hudparse.h
===================================================================
--- code/hud/hudparse.h	(revision 11274)
+++ code/hud/hudparse.h	(working copy)
@@ -29,7 +29,7 @@
 void load_missing_retail_gauges();
 void check_color(int *colorp);
 
-#define NUM_HUD_OBJECT_ENTRIES			56		// not used anywhere?
+#define NUM_HUD_OBJECT_ENTRIES			57		// not used anywhere?
 int parse_gauge_type();
 void load_gauge(int gauge, int base_w = -1, int base_h = -1, int font = -1, bool scale_gauge = true, SCP_vector<int>* ship_idx = NULL, color *use_clr = NULL);
 
@@ -201,4 +201,7 @@
 #define HUD_OBJECT_SECONDARY_WEAPONS	55
 void load_gauge_secondary_weapons(int base_w, int base_h, int font, bool scale_gauge = true, SCP_vector<int>* ship_idx = NULL, color *use_clr = NULL);
 
+#define HUD_OBJECT_DUMMY				56
+void load_gauge_dummy(int base_w, int base_h, int font, bool scale_gauge = true, SCP_vector<int>* ship_idx = NULL, color *use_clr = NULL);
+
 #endif // _HUDPARSE_H
3130.patch (9,855 bytes)   

MageKing17

2015-03-04 06:16

developer   ~0016535

Inability to disable kills gauge was probably due to inserting the entry in the wrong order in hudconfig.cpp; patch updated to hopefully fix that (although the fact that the crash still happened at all means that the dummy gauge isn't doing what it was expected to do).

The "different crash call stack" looks like "call stack 2" above, except with the addition of gr_opengl_string() in the stack trace... the odd part being that line 537 is the closing brace of the function. I guess that means some variable in that function is causing a crash due to going out of scope; the only non POD variable being declared in gr_opengl_string() would seem to be the GLboolean cull_face.

Before we go too far down this rabbit hole, it looks like there was another driver update last month: http://www.nvidia.com/download/driverResults.aspx/82061/en-us
Version: 347.52
Release Date: 2015.2.11

Might be worth trying one more time to see if the new drivers get rid of the issue.

MageKing17

2015-03-05 08:29

developer  

redundancy.patch (482 bytes)   
Index: code/graphics/gropenglstate.cpp
===================================================================
--- code/graphics/gropenglstate.cpp	(revision 11274)
+++ code/graphics/gropenglstate.cpp	(working copy)
@@ -218,6 +218,7 @@
 	}
 
 	if (units[active_texture_unit].texture_id != tex_id) {
+		glBindTexture(units[active_texture_unit].texture_target, 0);
 		glBindTexture(units[active_texture_unit].texture_target, tex_id);
 		units[active_texture_unit].texture_id = tex_id;
 	}
redundancy.patch (482 bytes)   

MageKing17

2015-03-05 08:31

developer   ~0016536

On a working assumption that the driver update won't fix the problem, I've attached another patch. This adds a glBindTexture() call immediately before the crashing one that binds the texture target to 0. This should be a completely redundant call that should have no effect whatsoever.

"Should" being the operative word.

chief1983

2015-03-09 15:07

administrator   ~0016539

Since we do have a workaround for this of disabling the kills gauge, plus it seems a smaller subset of users are still having issues at all now, there's talk of going ahead with the 3.7.2 final release without a final fix for this bug. Objections?

Inglonias

2015-03-09 16:28

reporter   ~0016540

Last edited: 2015-03-09 16:28

As one of the smaller subset of users who is still having this issue... yes?

EDIT: I'll use the workaround if I have to. No harm done.

chief1983

2015-03-09 16:34

administrator   ~0016541

You are? We were thinking that recent driver updates had almost narrowed it down to only Quadro users still affected by it. Are you able to reproduce the issue the same way Goober has been in the more recent posts in this thread? And disabling the kills gauge prevents the crash for you as well?

Inglonias

2015-03-09 16:36

reporter   ~0016542

Oh, that's right. I DID update my drivers didn't I? Huh.

I haven't tested it with the new drivers. Ignore my ramblings.

MageKing17

2015-03-09 16:37

developer   ~0016543

Inglonias, when asked for more information earlier, you never commented again; without feedback, we had no way of knowing you even still had the issue.

The best way to help track down the cause of this bug is to provide as much information as possible!

Inglonias

2015-03-09 16:43

reporter   ~0016544

Right, yes, but I was also told that more testing information was not needed at that point. Specifically, Goober said "I think that all the help testers can give has been given."

So really, it's Goober's fault. /sarcasm

If it helps, I'll try reproducing the bug again as soon as I have access to my desktop in a few minutes. (Someone else is using it)

Inglonias

2015-03-09 17:01

reporter   ~0016545

Alright, so I was on my desktop with a GTX 670. If it makes you feel better, I was staring right at the Psamtik as it fired in "Surrender, Bellisarius!" and the game doesn't crash.

Loading up Exodus, the game doesn't crash there either. I guess I'm not affected by this any more after all. As I said:
1. Ignore my mad ramblings
2. Goober. Blame him. It's his fault. Because I say so.

Goober5000

2015-03-10 03:05

administrator   ~0016546

When I said "I think that all the help testers can give has been given", I meant that the testers had narrowed down the location and context of the crash, and the next step was for someone with deep understanding of the graphics code to sit down, construct a fault tree, and start zeroing in on what might be causing the crash. That person never showed up. MageKing17 has been making a valiant attempt and is to be commended, but it amounts to throwing darts at the code to see if something gets hit. That's a lousy way to debug a problem. Nevertheless, because MageKing17 has been persevering, we owe it to him as testers to continue to provide feedback.

In short, Inglonias, my comment was directed at the developers, not the testers. It was meant to shame the graphics coders into showing up. :p

I've been busy over the past few days (painting, ugh) but I will update the drivers again and try MageKing17's latest patch.

Inglonias, are you *positive* that the game is running using the NVIDIA graphics processor and not Intelgrated or whatever the fallback is? If you have multiple processors you can right-click on the EXE and select "run with high performance processor" to make it explicit.

If Inglonias confirms that he's using the right processor, and if neither the driver update nor the latest patch solves the problem, AND if nobody else has the problem, then I will accede to closing this bug as "won't fix" and I'll just live with using the standard processor.

I will post again with the results of my tests shortly.

Goober5000

2015-03-10 04:23

administrator  

callstack w redundancy.txt (2,559 bytes)   
 	nvoglv32.dll!5df723e2() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]	
 	nvoglv32.dll!5df88f57() 	
 	nvoglv32.dll!5defb00e() 	
 	nvoglv32.dll!5deed64d() 	
 	nvoglv32.dll!5deee637() 	
 	nvoglv32.dll!5dee81fe() 	
 	nvoglv32.dll!5df75282() 	
>	fs2_open_3_7_1-DEBUG.exe!opengl_texture_state::Enable(unsigned int tex_id=255)  Line 221 + 0x1d bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set_internal(int bitmap_handle=332757, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int tex_unit=0)  Line 1067	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set(int bitmap_handle=332757, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int stage=0)  Line 1110 + 0x19 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!opengl_aabitmap_ex_internal(int x=880, int y=624, int w=81, int h=15, int sx=0, int sy=0, int resize_mode=1, bool mirror=false)  Line 80 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 306 + 0x31 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 699 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int x=880, int y=624)  Line 853 + 0x17 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int frame=332757, int x=880, int y=624)  Line 862	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGaugeKills::render(float frametime=0.0083312988)  Line 2469	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_gauges(int cockpit_display_num=-1)  Line 1847 + 0x35 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_all()  Line 1770 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_render_hud(camid cid={...})  Line 4265	C++
 	fs2_open_3_7_1-DEBUG.exe!game_frame(bool paused=false)  Line 4534 + 0x13 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_frame()  Line 4903 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_state(int state=2)  Line 6587	C++
 	fs2_open_3_7_1-DEBUG.exe!gameseq_process_events()  Line 409 + 0x14 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_main(char * cmdline=0x02b95344)  Line 7153 + 0x5 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x02b95344, int nCmdShow=10)  Line 7222 + 0x9 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!__tmainCRTStartup()  Line 324 + 0x35 bytes	C
 	fs2_open_3_7_1-DEBUG.exe!WinMainCRTStartup()  Line 196	C
 	kernel32.dll!7514338a() 	
 	ntdll.dll!77779f72() 	
 	ntdll.dll!77779f45() 	
callstack w redundancy.txt (2,559 bytes)   

Goober5000

2015-03-10 04:23

administrator  

units.txt (651 bytes)   
-units[active_texture_unit]	{active=0 enabled='' texture_target=3553 ...}	opengl_texture_unit
	active	0	unsigned char
	enabled	1 '␁'	unsigned char
	texture_target	3553	unsigned int
	texture_id	10	unsigned int
	texgen_S	0	unsigned char
	texgen_T	0	unsigned char
	texgen_R	0	unsigned char
	texgen_Q	0	unsigned char
	texgen_mode_S	9216	unsigned int
	texgen_mode_T	9216	unsigned int
	texgen_mode_R	9216	unsigned int
	texgen_mode_Q	9216	unsigned int
	env_mode	8448	unsigned int
	env_combine_rgb	8448	unsigned int
	env_combine_alpha	8448	unsigned int
	rgb_scale	1.0000000	float
	alpha_scale	1.0000000	float
	used	1 '␁'	unsigned char
units.txt (651 bytes)   

Goober5000

2015-03-10 04:28

administrator   ~0016547

Well now we're getting somewhere... I think. The bad news is that it still crashed after the driver update. The good news is that something unexpected happened: it crashed on the newly inserted line:

glBindTexture(units[active_texture_unit].texture_target, 0);

The bitmap_handle variable is still 332757 and still points to kills1.ani. On the assumption that this "units" struct has something to do with the crash, I've uploaded a variable watch for that reference. (The active_texture_unit variable itself is 0.)

MageKing17

2015-03-10 04:37

developer   ~0016548

Last edited: 2015-03-10 05:07

The texture_target is just GL_TEXTURE_2D (3553 == 0x0DE1, which is how GL_TEXTURE_2D is #defined in /code/graphics/gl/Gl.h). glBindTexture(GL_TEXTURE_2D, 0) is just saying "make the active 2D texture the default". The fact that it's crashing on what should be the safest, most boring OpenGL call means that the problem almost certainly lies elsewhere; something else is changing the state in such a fashion that the next glBindTexture() call is resulting in a crash.

EDIT: Does it still not crash with the kills gauge disabled?

EDIT2: I just noticed that neither gauge after the kills gauge in retail_gauges[] calls renderBitmap(). It's possible that this is the reason the dummy gauge failed; moving something that calls renderBitmap() after the kills gauge may cause that gauge to crash if the kills gauge is disabled.

Perhaps it's time to try moving HUD_OBJECT_KILLS up in retail_gauges[] until the crash stops occuring (swap it with the item above it one by one so we know which gauge is causing the OpenGL state to become corrupted).

EDIT3: Actually, HudGaugeEtsRetail() eventually winds up calling renderBitmapEx() which winds up in the same set of functions, and HudGaugeFixedMessages (HUD_OBJECT_FIXED_MESSAGES, immediately after HUD_OBJECT_KILLS) calls renderString(), which eventually ends up in gr_opengl_tcache_set() again. So... I dunno. Still want to know what happens if HUD_OBJECT_KILLS is moved up the list.

Inglonias

2015-03-10 05:46

reporter   ~0016549

Last edited: 2015-03-10 05:46

In regards to Goober asking if I'm sure about the crashing: What part of "Ignore my mad ramblings" do you not understand?

But, if it makes you happy, I loaded up Exodus on 3.7.2 RC5. Using a non-debug build. I was able to play the mission, and watch some beams before jumping out and being court marshalled. They were pretty.

Lack of a crash in this case from my end proves... that my copy of Freespace Open didn't crash. I don't know what else to say.

Goober, you don't HAVE to use the standard processor. Just disable the kills gauge. Nobody ever looks at it anyway!

Goober5000

2015-03-11 00:39

administrator   ~0016550

I don't think randomly shuffling HUD_OBJECT_KILLS is a good use of testing resources. It takes time to run each test, and every time the game crashes it takes longer to run the next test than the previous one.* Plus this is even more blatantly throwing darts than usual.

And it's not a good test either. It has only two possible outcomes: reordering the gauges will prevent the crash or the crash will keep happening. Neither outcome tells us anything.

You need to think strategically. It makes sense that the root cause lies elsewhere and what we're seeing is merely a symptom. This is consistent with NVIDIA's statement that malformed data can cause problems (though not conclusive). So, how might we check that the data isn't being corrupted or incorrectly constructed? What logging statements can we add? What Asserts can we add? Where should we expand our search? If we think that one of the other HUD gauges is corrupting the OpenGL state, is there some sort of sanity check that we can temporarily insert into each gauge's code? (This is what I meant by "construct a fault tree" and "zero in on the problem".)


*I assume this is caused by memory leaks due to the crash. The game will randomly freeze for a second or so, and every time it crashes and I run another test the freezes will occur more frequently. However, the crash is not dependent on whether or how frequent the freezing occurs.

Goober5000

2015-03-11 01:11

administrator   ~0016551

Because apparently I like to contradict myself, I ran a few tests with moving HUD_OBJECT_KILLS up a few indexes in the retail_gauges[] array. Turns out that the crash occurs if it is immediately below HUD_OBJECT_TARGET_TRI, but does not occur if it is immediately above it.

Goober5000

2015-03-11 01:12

administrator   ~0016552

(Note that usually HUD_OBJECT_KILLS is two spaces below HUD_OBJECT_TARGET_TRI, not one space.)

MageKing17

2015-03-11 02:12

developer   ~0016553

And that is exactly why I wanted you to move HUD_OBJECT_KILLS around; because now we know that we need to look at HudGaugeTargetTriangle for odd behavior. Not sure what's not strategic about wanting to find that out...

Given that, HUD_OBJECT_HOSTILE_TRI, HUD_OBJECT_TARGET_TRI, and HUD_OBJECT_MISSILE_TRI all use HudGaugeReticleTriangle::renderTriangle() for their drawing, there may be something wrong with that function that's causing the kills gauge to crash.

If you want to verify that renderTriangle() is causing the problem, you could try disabling the gauges that use it instead of the kills gauge (with HUD_OBJECT_KILLS in its original position, of course) and see if it still crashes. They're "locked missile direction" and "current target direction" (not "target orientation", which is HUD_OBJECT_ORIENTATION_TEE) in the in-game HUD config menu (HUD_OBJECT_HOSTILE_TRI can't be turned off via this menu, but since it didn't crash for you before with HUD_OBJECT_KILLS immediately below it, that probably won't be a problem for this test).

MageKing17

2015-03-11 03:51

developer  

hudtarget.cpp.patch (1,343 bytes)   
Index: code/hud/hudtarget.cpp
===================================================================
--- code/hud/hudtarget.cpp	(revision 11278)
+++ code/hud/hudtarget.cpp	(working copy)
@@ -2835,7 +2835,7 @@
 
 	verts[0].screen.xyw.x = x1;
 	verts[0].screen.xyw.y = y1;
-	verts[0].screen.xyw.w = 0.0f;
+	verts[0].screen.xyw.w = 0.1f;
 	verts[0].texture_position.u = 0.0f;
 	verts[0].texture_position.v = 0.0f;
 	verts[0].flags = PF_PROJECTED;
@@ -2847,7 +2847,7 @@
 
 	verts[1].screen.xyw.x = x2;	
 	verts[1].screen.xyw.y = y2;
-	verts[1].screen.xyw.w = 0.0f;
+	verts[1].screen.xyw.w = 0.1f;
 	verts[1].texture_position.u = 0.0f;
 	verts[1].texture_position.v = 0.0f;
 	verts[1].flags = PF_PROJECTED;
@@ -2859,7 +2859,7 @@
 
 	verts[2].screen.xyw.x = x3;
 	verts[2].screen.xyw.y = y3;
-	verts[2].screen.xyw.w = 0.0f;
+	verts[2].screen.xyw.w = 0.1f;
 	verts[2].texture_position.u = 0.0f;
 	verts[2].texture_position.v = 0.0f;
 	verts[2].flags = PF_PROJECTED;
@@ -2878,7 +2878,7 @@
 	gr_zbuffer_set( GR_ZBUFF_NONE );
 	
 	//gr_tmapper( 3, vertlist, TMAP_FLAG_TRILIST );
-	g3_draw_poly_constant_sw(3, vertlist, TMAP_FLAG_GOURAUD | TMAP_FLAG_RGB | TMAP_FLAG_ALPHA, 0.1f);	
+	g3_draw_poly_constant_sw(3, vertlist, TMAP_FLAG_GOURAUD | TMAP_FLAG_RGB | TMAP_FLAG_ALPHA | TMAP_FLAG_TRILIST, 0.1f);	
 
 	gr_zbuffer_set( saved_mode );
 	gr_set_cull(cull);
hudtarget.cpp.patch (1,343 bytes)   

MageKing17

2015-03-11 04:04

developer   ~0016554

For experimentation purposes, I've attached a patch that makes the triangles get drawn with an OpenGL mode of GL_TRIANGLES instead of GL_TRIANGLES_FAN. Theoretically there should be no difference between the two, but, well, theoretically, glBindTexture() shouldn't be crashing at all.

One last retail_gauges[] rearrangement test I'd like to see the results of is HUD_OBJECT_ETS_RETAIL swapped with HUD_OBJECT_KILLS. If the crash occurs in HudGaugeEtsRetail, then we'll know that there's no difference between renderBitmap() and renderBitmapEx(), and then maybe we can take a look at why HudGaugeFixedMessages::render() not only doesn't trigger the crash, but fixes the problem for gauges rendered afterwards.

(If HudGaugeEtsRetail doesn't crash, then we'll be freaking out because there's very little difference between gr_opengl_aabitmap() and gr_opengl_aabitmap_ex(); they both call opengl_aabitmap_ex_internal().)

Goober5000

2015-03-15 06:15

administrator   ~0016556

With the kills gauge in the original place, I disabled "locked missile direction" and "current target direction". No crash. Then I re-enabled "current target direction" and got a completely different crash at the same time instant: the one shown in the "enabling triangles" attachment.

I'll try your triangles patch next, but I need to restart first. Too many memory leaks...

Goober5000

2015-03-15 06:16

administrator  

enabling triangles.txt (2,546 bytes)   
Unhandled exception at 0x774be41b in fs2_open_3_7_1-DEBUG.exe: 0xC0000005: Access violation writing location 0x00000000.

 	ntdll.dll!774be41b() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
>	fs2_open_3_7_1-DEBUG.exe!std::_Uninit_move<int *,int *,SCP_vm_allocator<int>,std::_Undefined_move_tag>(int * _First=0x0dddd5e8, int * _Last=0x00000001, int * _Dest=0x0018ebfc, SCP_vm_allocator<int> & _Al={...}, std::_Undefined_move_tag __formal={...}, std::_Undefined_move_tag __formal={...})  Line 206 + 0x15 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!_vm_free(void * ptr=0x0dddd5e8, char * filename=0x01232c18, int line=77)  Line 1875 + 0xb bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!SCP_vm_allocator<int>::deallocate(int * p=0x0dddd5e8, unsigned int __formal=3)  Line 77 + 0x10 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!std::vector<int,SCP_vm_allocator<int> >::_Insert_n(std::_Vector_iterator<int,SCP_vm_allocator<int> > _Where=-572662307, unsigned int _Count=4, const int & _Val=24)  Line 1163	C++
 	fs2_open_3_7_1-DEBUG.exe!std::vector<int,SCP_vm_allocator<int> >::insert(std::_Vector_iterator<int,SCP_vm_allocator<int> > _Where=-572662307, const int & _Val=24)  Line 855	C++
 	fs2_open_3_7_1-DEBUG.exe!std::vector<int,SCP_vm_allocator<int> >::push_back(const int & _Val=24)  Line 800 + 0x2d bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!obj_find_overlap_colliders(SCP_vector<int> * overlap_list_out=0x0018f21c, SCP_vector<int> * list=0x029d03e0, int axis=0, bool collide=false)  Line 1290	C++
 	fs2_open_3_7_1-DEBUG.exe!obj_sort_and_collide()  Line 1228 + 0x12 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!obj_move_all(float frametime=0.017013550)  Line 1510	C++
 	fs2_open_3_7_1-DEBUG.exe!game_simulation_frame()  Line 4094 + 0x1c bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_frame(bool paused=false)  Line 4487 + 0x12 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_frame()  Line 4903 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_state(int state=2)  Line 6587	C++
 	fs2_open_3_7_1-DEBUG.exe!gameseq_process_events()  Line 409 + 0x14 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_main(char * cmdline=0x02f45344)  Line 7153 + 0x5 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x02f45344, int nCmdShow=10)  Line 7222 + 0x9 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!__tmainCRTStartup()  Line 324 + 0x35 bytes	C
 	fs2_open_3_7_1-DEBUG.exe!WinMainCRTStartup()  Line 196	C
 	kernel32.dll!74e9338a() 	
 	ntdll.dll!774c9f72() 	
 	ntdll.dll!774c9f45() 	
enabling triangles.txt (2,546 bytes)   

Goober5000

2015-03-15 06:56

administrator   ~0016557

Last edited: 2015-03-15 06:57

First I swapped HUD_OBJECT_ETS_RETAIL with HUD_OBJECT_KILLS. No crash at all.

Then I reverted the code, added your TMAP_FLAG_TRILIST patch (the hudtarget.cpp.patch uploaded on March 10), created a new pilot. Crashed immediately. (That patch doesn't seem to contain either GL_TRIANGLES or GL_TRIANGLES_FAN; do I have the right patch?)

MageKing17

2015-03-15 08:06

developer   ~0016558

"That patch doesn't seem to contain either GL_TRIANGLES or GL_TRIANGLES_FAN; do I have the right patch?"

Yes. It adds a flag that causes a later function to use GL_TRIANGLES instead of GL_TRIANGLES_FAN. It shouldn't have made a difference, and it didn't. Good to know.

"First I swapped HUD_OBJECT_ETS_RETAIL with HUD_OBJECT_KILLS. No crash at all."

This is mind-boggling. HudGaugeEtsRetail calls calls a function that calls HudGauge::renderBitmapEx(), which follows an extremely similar to codepath to HudGauge::renderBitmap(), so I don't--

...Huh. I guess it does call HudGauge::renderPrintf() before that (to draw the "G", "S", "E" labels), so maybe that's why it doesn't crash. I guess that makes more sense than HudGaugeFixedMessages::render() fixing anything, since it shouldn't actually do anything most of the time. I wonder why gr_opengl_string() getting called avoids the crash, given that it also calls gr_opengl_tcache_set().

...In fact, in terms of actual OpenGL calls, the two should be doing exactly the same thing, up to the point where the kills gauge crashes. Both gr_opengl_string() and opengl_aabitmap_ex_internal() do the following things in the following order (with identical code):

GL_state.SetTextureSource(TEXTURE_SOURCE_NO_FILTERING);
GL_state.SetAlphaBlendMode(ALPHA_BLEND_ALPHA_BLEND_ALPHA);
GL_state.SetZbufferType(ZBUFFER_TYPE_NONE);

if ( !gr_opengl_tcache_set(gr_screen.current_bitmap, TCACHE_TYPE_AABITMAP, &u_scale, &v_scale) ) {

Goober5000

2015-03-16 04:24

administrator   ~0016559

Last edited: 2015-03-16 04:29

Did your comment get truncated? Not sure if your code snippet is meant to go to the closing brace, or if you were going to propose another test.

MageKing17

2015-03-16 04:33

developer   ~0016560

No, I stopped quoting on the line that the kills gauge crashed on, and I have no other suggestions given there shouldn't actually be any difference in OpenGL calls between those two gauges.

Goober5000

2015-03-16 15:10

administrator   ~0016561

Did you get anything out of the "enabling triangles.txt" stack trace?

MageKing17

2015-03-16 16:44

developer   ~0016562

Given that it happened in std::_Uninit_move(), I'm pretty sure there's memory corruption going on. At this point my recommendation is to reorder retail_gauges[] and/or immerse the computer in holy water before nuking it from orbit, then try to forget this ever happened.

chief1983

2015-03-16 16:59

administrator   ~0016563

Reordering sounds like a slightly better solution than asking people to disable their kills gauge, and I'm fine to release 3.7.2 with that but it would still be nice to someday understand this behavior more fully.

Goober5000

2015-03-17 02:07

administrator   ~0016564

Let's not "fix" it by reordering the array, otherwise the problem may manifest it in a different mysterious way and we'll be back to the wild goose chase again.

We really need someone who has a solid knowledge of the graphics code and can audit our API calls to make sure the data is passed in properly. (Or who at least knows what Assertions to put in place that can more precisely detect the problem.) Do we have nobody on the SCP who can fill that role?

MageKing17

2015-03-22 07:16

developer   ~0016571

Swifty just found an interesting potential problem while working on the deferred+shadows branch: http://www.hard-light.net/forums/index.php?topic=89379.0

Does this patch affect the issue in any way?

Goober5000

2015-03-23 06:08

administrator  

swifty.patch (1,553 bytes)   
Index: code/graphics/gropenglstate.cpp
===================================================================
--- code/graphics/gropenglstate.cpp	(revision 11284)
+++ code/graphics/gropenglstate.cpp	(working copy)
@@ -225,13 +225,13 @@
 	units[active_texture_unit].active = GL_TRUE;
 }
 
-void opengl_texture_state::Disable(bool force)
+void opengl_texture_state::Disable()
 {
-	if ( !force && !units[active_texture_unit].active ) {
+	if ( !units[active_texture_unit].active ) {
 		return;
 	}
 
-	if (force || units[active_texture_unit].enabled) {
+	if (units[active_texture_unit].enabled) {
 		glDisable( units[active_texture_unit].texture_target );
 		units[active_texture_unit].enabled = GL_FALSE;
 	}
@@ -252,7 +252,7 @@
 	for (unsigned int i = 0; i < num_texture_units; i++) {
 		if (!units[i].used) {
 			SetActiveUnit(i);
-			Disable(true);
+			Disable();
 		}
 	}
 }
@@ -262,7 +262,7 @@
 	for (unsigned int i = 0; i < num_texture_units; i++) {
 		if (units[i].active) {
 			SetActiveUnit(i);
-			Disable(true);
+			Disable();
 		}
 	}
 
Index: code/graphics/gropenglstate.h
===================================================================
--- code/graphics/gropenglstate.h	(revision 11284)
+++ code/graphics/gropenglstate.h	(working copy)
@@ -70,7 +70,7 @@
 		void SetTarget(GLenum tex_target);
 		void SetActiveUnit(GLuint id = 0);
 		void Enable(GLuint tex_id = 0);
-		void Disable(bool force = false);
+		void Disable();
 		void DisableUnused();
 		void DisableAll();
 		void ResetUsed();
swifty.patch (1,553 bytes)   

Goober5000

2015-03-23 06:12

administrator   ~0016572

Alas, no effect. It crashes in the same place.

Goober5000

2015-03-27 01:32

administrator   ~0016578

On a whim, I decided to try the nightly builds in case this was due to a compiler optimization issue like the infamous Y targeting bug. No such luck. The standard, SSE, and no-SSE builds all crashed.

chief1983

2015-03-27 13:49

administrator   ~0016579

How about Swifty's deferred lighting branch? If it doesn't crash that way for you, then surely this is just a temporary issue at worst that is already resolved in what will be merged into trunk soon anyway.

Goober5000

2015-03-28 02:23

administrator   ~0016582

I thought I had posted about that but I guess not. No, neither Swifty's patch against trunk nor Swifty's full branch fixes the crash.

chief1983

2015-03-28 12:54

administrator   ~0016584

I might have missed it if you had but it's good to have documentation here. Still, I think we're going to have to release without knowing the full cause of the issue at this point. Can we get a reordering patch that at least works around the issue so anyone on Goober's hardware wouldn't have to disable the kills gauge?

Goober5000

2015-03-28 18:57

administrator   ~0016585

I don't want to "fix" it with a reordering patch. It'll just hide the issue and it's possible that it will then be caused by some other strange combination of settings and we'll have to track it down all over again.

So far no graphics coder has taken a serious look at this ticket. Since Swifty is knowledgeable in the ways of OpenGL I want him to take a look first. If he's stumped too, then we can release.

chief1983

2015-03-29 03:47

administrator   ~0016586

I appreciate that we do want to get the root cause of this issue fixed, but as it seems to only currently affect an incredibly narrow set of circumstances, of which the ones we're aware of we can work around, I think it's safe to go with the workaround now and see if Swifty can investigate down the road, possibly with his deferred lighting branch which he is probably more comfortable with at this point. I've been requested by our commander in chief to get a release out very soon and don't think we should be waiting any longer for this issue.

Goober5000

2015-03-29 04:41

administrator   ~0016587

The workaround we know of is to disable the kills gauge. That's reasonable as a workaround. But if we apply a code hack that we neither understand nor know the consequences of, it could backfire. It's better to release with a known bug than a buried land mine.

However, I have managed to find a knowledgeable person who provided some diagnostic logging statements and has a test plan. Let's wait to see how that pans out first.

The_E

2015-03-29 08:11

administrator   ~0016588

Let's not. This issue seems to be fixed for most people affected due to driver updates, and we've held up this release for far too long already.

I fully understand that the workarounds available are bad. I would absolutely prefer to ship 3.7.2 with this bug understood, fixed and buried, but without some sort of timeframe for this fix, and workarounds available, I'd rather we not keep everyone else waiting.

m_m

2015-03-29 16:38

developer   ~0016589

@Goober: We could try looking at the OpenGL calls FSO executes. Can you install GLIntercept (https://code.google.com/p/glintercept/wiki/Downloads?tm=2) and use the FullDebug mode while reproducing the crash?
For comparison it could also help if you provide a glintercept log for when you have the kills gauge disabled. Maybe that will show if something is wrong.

Goober5000

2015-03-29 17:16

administrator   ~0016590

The E, the timeframe is very short: just a matter of days. We're already making some significant progress -- for instance, we've discovered that the crash occurs on glIsTexture(), not just glBindTexture(), and we've ruled out certain graphics modes.

m!m, I'll take a look at that.

Swifty

2015-03-29 21:45

developer   ~0016591

Last edited: 2015-03-29 21:51

Some thoughts:

- Can anyone who can reproduce this issue try running with a build before 11165? Perhaps my changes to gr_opengl_string is causing issues.

- While we're on that, can someone try to run the code before the large amount of Xt changes were merged in? The changes that prompted my changes to gr_opengl_string were because of the gr_opengl_string changes from the Xt merges. Basically run a build before 11116.

- Just for the interests of science, can someone comment out the line with renderBitmap in HudGaugeKills::render and see what happens?

- Also try to comment out beam_render, beam_render_muzzle_glow, or beam_generate_muzzle_particles to see what happens.

- Also try out pabst_bleu_ribbon (https://github.com/SamuelCho/Freespace-Open-Swifty/tree/pabst_bleu_ribbon) to see if the bug is persisting there. I replaced all fixed function rendering with a passthrough shader. Maybe Nvidia's drivers aren't very tolerant of fixed function rendering anymore.

Goober5000

2015-03-30 03:02

administrator   ~0016592

Doesn't seem to be due to the Xt changes. Revision 11115 crashes.

Commenting out the renderBitmap line prevents the crash. But commenting out beam_render, beam_render_muzzle_glow, or beam_generate_muzzle_particles does not.

I checked out the PBR branch and that doesn't crash, but there are no stars and all the ships are black silhouettes.

Goober5000

2015-03-30 03:49

administrator   ~0016593

M!m, there is no crash when running using GLIntercept. This actually makes sense if GLIntercept uses debug code and the crash is due to a data problem, because garbage values would be sanitized to NULL or other known values.

Goober5000

2015-04-02 04:43

administrator   ~0016597

Just a quick update to say that progress is being made. We have some debugging callbacks running in the OpenGL functions now.

chief1983

2015-04-07 19:09

administrator   ~0016608

All right, progress is nice but seriously, we need like daily updates at this point to keep justifying waiting on this bug.

Goober5000

2015-04-08 04:28

administrator   ~0016620

Sorry, Easter intervened. We're back in contact now though.

Unfortunately the OpenGL debug callback is *itself* crashing, which is leaving us both stumped. I want to give this another day or two, but if after that time we haven't figured it out, then I'll punt and we can release.

So start warming up your release script, and someone should do a quick pass through the tickets to make sure there are no patches for fixed bugs waiting to be committed.

Goober5000

2015-04-08 05:42

administrator   ~0016621

Actually I may have spoken too soon. I found a way to get the debug callback to run, and I've sent along the appropriate logs. Hopefully they can provide a clue to solving this.

Or they may tell us nothing, in which case revert to my previous comment.

Swifty

2015-04-08 07:49

developer  

desaturate_fix.patch (2,863 bytes)   
Index: globalincs/def_files.cpp
===================================================================
--- globalincs/def_files.cpp	(revision 11296)
+++ globalincs/def_files.cpp	(working copy)
@@ -1348,9 +1348,7 @@
 "#ifdef FLAG_DIFFUSE_MAP\n"
 "uniform sampler2D sBasemap;\n"
 "uniform int desaturate;\n"
-"uniform float desaturate_r;\n"
-"uniform float desaturate_g;\n"
-"uniform float desaturate_b;\n"
+"uniform vec3 desaturate_clr;\n"
 "#endif\n"
 "#ifdef FLAG_GLOW_MAP\n"
 "uniform sampler2D sGlowmap;\n"
@@ -1569,13 +1567,7 @@
 "	}\n"
 " #else\n"
 "	#ifdef FLAG_DIFFUSE_MAP\n"
-"		if(desaturate == 1) {\n"
-"			float intensity = 0.0;\n"
-"			intensity = (fragmentColor.r + fragmentColor.g + fragmentColor.b)/3.0;\n"
-"			float alpha = fragmentColor.a;\n"
-"			fragmentColor = vec4(desaturate_r, desaturate_g, desaturate_b, 1.0) * intensity;\n"
-"			fragmentColor.a = alpha;\n"
-"		}\n"
+"	fragmentColor.rgb = mix(fragmentColor.rgb, desaturate_clr * dot(vec3(1.0), fragmentColor.rgb) * 0.3333333, float(desaturate));\n"
 "	#endif\n"
 "	gl_FragColor = fragmentColor;\n"
 " #endif\n"
Index: graphics/gropenglshader.cpp
===================================================================
--- graphics/gropenglshader.cpp	(revision 11296)
+++ graphics/gropenglshader.cpp	(working copy)
@@ -47,7 +47,7 @@
 static opengl_shader_uniform_reference_t GL_Uniform_Reference_Main[] = {
 	{ SDR_FLAG_LIGHT,		1, {"n_lights"}, 0, { NULL }, "Lighting" },
 	{ SDR_FLAG_FOG,			0, { NULL }, 0, { NULL }, "Fog Effect" },
-	{ SDR_FLAG_DIFFUSE_MAP, 5, {"sBasemap", "desaturate", "desaturate_r", "desaturate_g", "desaturate_b"}, 0, { NULL }, "Diffuse Mapping"},
+	{ SDR_FLAG_DIFFUSE_MAP, 3, {"sBasemap", "desaturate", "desaturate_clr"}, 0, { NULL }, "Diffuse Mapping"},
 	{ SDR_FLAG_GLOW_MAP,	1, {"sGlowmap"}, 0, { NULL }, "Glow Mapping" },
 	{ SDR_FLAG_SPEC_MAP,	1, {"sSpecmap"}, 0, { NULL }, "Specular Mapping" },
 	{ SDR_FLAG_NORMAL_MAP,	1, {"sNormalmap"}, 0, { NULL }, "Normal Mapping" },
Index: graphics/gropengltnl.cpp
===================================================================
--- graphics/gropengltnl.cpp	(revision 11296)
+++ graphics/gropengltnl.cpp	(working copy)
@@ -715,9 +715,8 @@
 		}
 
 		vglUniform1iARB( opengl_shader_get_uniform("desaturate"), desaturate);
-		vglUniform1fARB( opengl_shader_get_uniform("desaturate_r"), gr_screen.current_color.red/255.0f);
-		vglUniform1fARB( opengl_shader_get_uniform("desaturate_g"), gr_screen.current_color.green/255.0f);
-		vglUniform1fARB( opengl_shader_get_uniform("desaturate_b"), gr_screen.current_color.blue/255.0f);
+		vglUniform3fARB( opengl_shader_get_uniform("desaturate_clr"), 
+			gr_screen.current_color.red/255.0f, gr_screen.current_color.green/255.0f, gr_screen.current_color.blue/255.0f);
 
 		gr_opengl_tcache_set(gr_screen.current_bitmap, tmap_type, &u_scale, &v_scale, render_pass);
 	
desaturate_fix.patch (2,863 bytes)   

Swifty

2015-04-08 07:54

developer   ~0016622

So, I took a careful look at the logs posted in this ticket and I noticed the shaders are displaying a lot of warnings related to the desaturate uniforms in the model rendering shaders. Unfortunately hose warnings don't seem to appear on any other machine I compile those shaders on (Notably an AMD Radeon 290, a Geforce 750M, a Geforce 750M with Mac drivers, and a Geforce 470 GTX). So, this is just a stab in the dark to see if this little bit of code cleanup will fix the issue. Check the attached desaturate_fix.patch file I've uploaded.

I've also noticed that each log file seem to end with the Diffuse and Glow Map shader variant is compiled so I tried to see if there's anything peculiar about the #defines and the #ifdefs concerning glow maps and diffuse in the shaders but I've found nothing.

Goober5000

2015-04-09 03:10

administrator  

desaturate-callstack.txt (2,559 bytes)   
 	nvoglv32.dll!5ae423e2() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]	
 	nvoglv32.dll!5ae58f57() 	
 	nvoglv32.dll!5adcb00e() 	
 	nvoglv32.dll!5adbd64d() 	
 	nvoglv32.dll!5adbe637() 	
 	nvoglv32.dll!5adb81fe() 	
 	nvoglv32.dll!5ae45282() 	
>	fs2_open_3_7_1-DEBUG.exe!opengl_texture_state::Enable(unsigned int tex_id=255)  Line 221 + 0x1f bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set_internal(int bitmap_handle=332757, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int tex_unit=0)  Line 1067	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set(int bitmap_handle=332757, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int stage=0)  Line 1110 + 0x19 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!opengl_aabitmap_ex_internal(int x=880, int y=624, int w=81, int h=15, int sx=0, int sy=0, int resize_mode=1, bool mirror=false)  Line 80 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 306 + 0x31 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 699 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int x=880, int y=624)  Line 853 + 0x17 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int frame=332757, int x=880, int y=624)  Line 862	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGaugeKills::render(float frametime=0.0083312988)  Line 2469	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_gauges(int cockpit_display_num=-1)  Line 1847 + 0x35 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_all()  Line 1770 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_render_hud(camid cid={...})  Line 4265	C++
 	fs2_open_3_7_1-DEBUG.exe!game_frame(bool paused=false)  Line 4534 + 0x13 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_frame()  Line 4903 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_state(int state=2)  Line 6587	C++
 	fs2_open_3_7_1-DEBUG.exe!gameseq_process_events()  Line 409 + 0x14 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_main(char * cmdline=0x02f65534)  Line 7153 + 0x5 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x02f65534, int nCmdShow=10)  Line 7222 + 0x9 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!__tmainCRTStartup()  Line 324 + 0x35 bytes	C
 	fs2_open_3_7_1-DEBUG.exe!WinMainCRTStartup()  Line 196	C
 	kernel32.dll!750e338a() 	
 	ntdll.dll!77709f72() 	
 	ntdll.dll!77709f45() 	
desaturate-callstack.txt (2,559 bytes)   

Goober5000

2015-04-09 03:11

administrator  

desaturate-fs2_open.log (404,039 bytes)

Goober5000

2015-04-09 03:13

administrator   ~0016627

Last edited: 2015-04-09 03:13

Alas, the desaturate patch didn't fix the beam crash. I've attached the stack trace and log anyway.

On my end, we found and fixed a VBO configuration error and generated a new batch of logs. No smoking gun yet.

Goober5000

2015-04-10 02:29

administrator   ~0016632

Well, poo. The debug callbacks into the OpenGL functions told us exactly nothing useful. Which means we're out of ideas.

Time to punt on this and release 3.7.2. It sucks, but what are you going to do.

Swifty

2015-04-10 03:01

developer  

shader_mode_hunch.patch (4,404 bytes)   
Index: globalincs/def_files.cpp
===================================================================
--- globalincs/def_files.cpp	(revision 11296)
+++ globalincs/def_files.cpp	(working copy)
@@ -1348,9 +1348,7 @@
 "#ifdef FLAG_DIFFUSE_MAP\n"
 "uniform sampler2D sBasemap;\n"
 "uniform int desaturate;\n"
-"uniform float desaturate_r;\n"
-"uniform float desaturate_g;\n"
-"uniform float desaturate_b;\n"
+"uniform vec3 desaturate_clr;\n"
 "#endif\n"
 "#ifdef FLAG_GLOW_MAP\n"
 "uniform sampler2D sGlowmap;\n"
@@ -1569,13 +1567,7 @@
 "	}\n"
 " #else\n"
 "	#ifdef FLAG_DIFFUSE_MAP\n"
-"		if(desaturate == 1) {\n"
-"			float intensity = 0.0;\n"
-"			intensity = (fragmentColor.r + fragmentColor.g + fragmentColor.b)/3.0;\n"
-"			float alpha = fragmentColor.a;\n"
-"			fragmentColor = vec4(desaturate_r, desaturate_g, desaturate_b, 1.0) * intensity;\n"
-"			fragmentColor.a = alpha;\n"
-"		}\n"
+"	fragmentColor.rgb = mix(fragmentColor.rgb, desaturate_clr * dot(vec3(1.0), fragmentColor.rgb) * 0.3333333, float(desaturate));\n"
 "	#endif\n"
 "	gl_FragColor = fragmentColor;\n"
 " #endif\n"
Index: graphics/gropengldraw.cpp
===================================================================
--- graphics/gropengldraw.cpp	(revision 11296)
+++ graphics/gropengldraw.cpp	(working copy)
@@ -1651,6 +1651,7 @@
 					return;
 				}
 				opengl_shader_set_current(&GL_shader[sdr_index]);
+				GL_state.Texture.SetShaderMode(GL_TRUE);
 				
 				vglUniform1iARB(opengl_shader_get_uniform("frameBuffer"), 2);
 				
@@ -1679,6 +1680,7 @@
 					return;
 				}
 				opengl_shader_set_current(&GL_shader[sdr_index]);
+				GL_state.Texture.SetShaderMode(GL_TRUE);
 				zbuff = gr_zbuffer_set(GR_ZBUFF_NONE);
 			}
 
@@ -1765,6 +1767,7 @@
 		GL_state.Array.DisableVertexAttrib(attrib_index);
 	}
 
+	GL_state.Texture.SetShaderMode(GL_FALSE);
 	GL_state.CullFace(cull_face);
 	GL_state.Lighting(lighting);
 	gr_zbuffer_set(zbuff);
Index: graphics/gropenglshader.cpp
===================================================================
--- graphics/gropenglshader.cpp	(revision 11296)
+++ graphics/gropenglshader.cpp	(working copy)
@@ -47,7 +47,7 @@
 static opengl_shader_uniform_reference_t GL_Uniform_Reference_Main[] = {
 	{ SDR_FLAG_LIGHT,		1, {"n_lights"}, 0, { NULL }, "Lighting" },
 	{ SDR_FLAG_FOG,			0, { NULL }, 0, { NULL }, "Fog Effect" },
-	{ SDR_FLAG_DIFFUSE_MAP, 5, {"sBasemap", "desaturate", "desaturate_r", "desaturate_g", "desaturate_b"}, 0, { NULL }, "Diffuse Mapping"},
+	{ SDR_FLAG_DIFFUSE_MAP, 3, {"sBasemap", "desaturate", "desaturate_clr"}, 0, { NULL }, "Diffuse Mapping"},
 	{ SDR_FLAG_GLOW_MAP,	1, {"sGlowmap"}, 0, { NULL }, "Glow Mapping" },
 	{ SDR_FLAG_SPEC_MAP,	1, {"sSpecmap"}, 0, { NULL }, "Specular Mapping" },
 	{ SDR_FLAG_NORMAL_MAP,	1, {"sNormalmap"}, 0, { NULL }, "Normal Mapping" },
Index: graphics/gropengltnl.cpp
===================================================================
--- graphics/gropengltnl.cpp	(revision 11296)
+++ graphics/gropengltnl.cpp	(working copy)
@@ -715,9 +715,8 @@
 		}
 
 		vglUniform1iARB( opengl_shader_get_uniform("desaturate"), desaturate);
-		vglUniform1fARB( opengl_shader_get_uniform("desaturate_r"), gr_screen.current_color.red/255.0f);
-		vglUniform1fARB( opengl_shader_get_uniform("desaturate_g"), gr_screen.current_color.green/255.0f);
-		vglUniform1fARB( opengl_shader_get_uniform("desaturate_b"), gr_screen.current_color.blue/255.0f);
+		vglUniform3fARB( opengl_shader_get_uniform("desaturate_clr"), 
+			gr_screen.current_color.red/255.0f, gr_screen.current_color.green/255.0f, gr_screen.current_color.blue/255.0f);
 
 		gr_opengl_tcache_set(gr_screen.current_bitmap, tmap_type, &u_scale, &v_scale, render_pass);
 	
@@ -1353,6 +1352,7 @@
 					glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
 
 					opengl_shader_set_current(&GL_shader[sdr_index]);
+					GL_state.Texture.SetShaderMode(GL_TRUE);
 					Stream_buffer_sdr = sdr_index;
 
 					vglUniform1iARB(opengl_shader_get_uniform("baseMap"), 0);
@@ -1397,6 +1397,7 @@
 
 				if ( sdr_index != Stream_buffer_sdr ) {
 					opengl_shader_set_current(&GL_shader[sdr_index]);
+					GL_state.Texture.SetShaderMode(GL_TRUE);
 					Stream_buffer_sdr = sdr_index;
 
 					vglUniform1iARB(opengl_shader_get_uniform("baseMap"), 0);
@@ -1468,6 +1469,8 @@
 		vglDrawBuffers(2, buffers);
 	}
 	
+	GL_state.Texture.SetShaderMode(GL_FALSE);
+
 	GL_CHECK_FOR_ERRORS("end of render3d()");
 }
 
shader_mode_hunch.patch (4,404 bytes)   

Swifty

2015-04-10 03:06

developer   ~0016634

Another patch to try. I noticed that we never call SetShaderMode on the texture unit state handlers when rendering soft particles. Maybe us calling glEnable on a texture unit being used in shader draw calls is causing issues?

Goober5000

2015-04-10 04:13

administrator  

hunch-callstack.txt (2,558 bytes)   
 	nvoglv32.dll!5cf023e2() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]	
 	nvoglv32.dll!5cf18f57() 	
 	nvoglv32.dll!5ce8b00e() 	
 	nvoglv32.dll!5ce7d64d() 	
 	nvoglv32.dll!5ce7e637() 	
 	nvoglv32.dll!5ce781fe() 	
 	nvoglv32.dll!5cf05282() 	
>	fs2_open_3_7_1-DEBUG.exe!opengl_texture_state::Enable(unsigned int tex_id=255)  Line 221 + 0x1f bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set_internal(int bitmap_handle=332757, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int tex_unit=0)  Line 1067	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set(int bitmap_handle=332757, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int stage=0)  Line 1110 + 0x19 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!opengl_aabitmap_ex_internal(int x=880, int y=624, int w=81, int h=15, int sx=0, int sy=0, int resize_mode=1, bool mirror=false)  Line 80 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 306 + 0x31 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 699 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int x=880, int y=624)  Line 853 + 0x17 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int frame=332757, int x=880, int y=624)  Line 862	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGaugeKills::render(float frametime=0.026992798)  Line 2469	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_gauges(int cockpit_display_num=-1)  Line 1847 + 0x35 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_all()  Line 1770 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_render_hud(camid cid={...})  Line 4265	C++
 	fs2_open_3_7_1-DEBUG.exe!game_frame(bool paused=false)  Line 4534 + 0x13 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_frame()  Line 4903 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_state(int state=2)  Line 6587	C++
 	fs2_open_3_7_1-DEBUG.exe!gameseq_process_events()  Line 409 + 0x14 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_main(char * cmdline=0x02b85534)  Line 7153 + 0x5 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x02b85534, int nCmdShow=10)  Line 7222 + 0x9 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!__tmainCRTStartup()  Line 324 + 0x35 bytes	C
 	fs2_open_3_7_1-DEBUG.exe!WinMainCRTStartup()  Line 196	C
 	kernel32.dll!7623338a() 	
 	ntdll.dll!77cf9f72() 	
 	ntdll.dll!77cf9f45() 	
hunch-callstack.txt (2,558 bytes)   

Goober5000

2015-04-10 04:13

administrator  

hunch-fs2_open.log (403,794 bytes)

Goober5000

2015-04-10 04:13

administrator   ~0016635

I applied the patch to clean trunk. Alas, it crashed just as before. Logs attached.

Swifty

2015-04-10 04:17

developer  

hunch2.patch (4,582 bytes)   
Index: globalincs/def_files.cpp
===================================================================
--- globalincs/def_files.cpp	(revision 11296)
+++ globalincs/def_files.cpp	(working copy)
@@ -1348,9 +1348,7 @@
 "#ifdef FLAG_DIFFUSE_MAP\n"
 "uniform sampler2D sBasemap;\n"
 "uniform int desaturate;\n"
-"uniform float desaturate_r;\n"
-"uniform float desaturate_g;\n"
-"uniform float desaturate_b;\n"
+"uniform vec3 desaturate_clr;\n"
 "#endif\n"
 "#ifdef FLAG_GLOW_MAP\n"
 "uniform sampler2D sGlowmap;\n"
@@ -1569,13 +1567,7 @@
 "	}\n"
 " #else\n"
 "	#ifdef FLAG_DIFFUSE_MAP\n"
-"		if(desaturate == 1) {\n"
-"			float intensity = 0.0;\n"
-"			intensity = (fragmentColor.r + fragmentColor.g + fragmentColor.b)/3.0;\n"
-"			float alpha = fragmentColor.a;\n"
-"			fragmentColor = vec4(desaturate_r, desaturate_g, desaturate_b, 1.0) * intensity;\n"
-"			fragmentColor.a = alpha;\n"
-"		}\n"
+"	fragmentColor.rgb = mix(fragmentColor.rgb, desaturate_clr * dot(vec3(1.0), fragmentColor.rgb) * 0.3333333, float(desaturate));\n"
 "	#endif\n"
 "	gl_FragColor = fragmentColor;\n"
 " #endif\n"
Index: graphics/gropengldraw.cpp
===================================================================
--- graphics/gropengldraw.cpp	(revision 11296)
+++ graphics/gropengldraw.cpp	(working copy)
@@ -1510,6 +1510,8 @@
 
 			texture_matrix_set = true;
 		}
+	} else {
+		GL_state.Texture.DisableAll();
 	}
 
 	if ( (flags & TMAP_FLAG_RGB) && (flags & TMAP_FLAG_GOURAUD) ) {
@@ -1651,6 +1653,7 @@
 					return;
 				}
 				opengl_shader_set_current(&GL_shader[sdr_index]);
+				GL_state.Texture.SetShaderMode(GL_TRUE);
 				
 				vglUniform1iARB(opengl_shader_get_uniform("frameBuffer"), 2);
 				
@@ -1679,6 +1682,7 @@
 					return;
 				}
 				opengl_shader_set_current(&GL_shader[sdr_index]);
+				GL_state.Texture.SetShaderMode(GL_TRUE);
 				zbuff = gr_zbuffer_set(GR_ZBUFF_NONE);
 			}
 
@@ -1765,6 +1769,7 @@
 		GL_state.Array.DisableVertexAttrib(attrib_index);
 	}
 
+	GL_state.Texture.SetShaderMode(GL_FALSE);
 	GL_state.CullFace(cull_face);
 	GL_state.Lighting(lighting);
 	gr_zbuffer_set(zbuff);
Index: graphics/gropenglshader.cpp
===================================================================
--- graphics/gropenglshader.cpp	(revision 11296)
+++ graphics/gropenglshader.cpp	(working copy)
@@ -47,7 +47,7 @@
 static opengl_shader_uniform_reference_t GL_Uniform_Reference_Main[] = {
 	{ SDR_FLAG_LIGHT,		1, {"n_lights"}, 0, { NULL }, "Lighting" },
 	{ SDR_FLAG_FOG,			0, { NULL }, 0, { NULL }, "Fog Effect" },
-	{ SDR_FLAG_DIFFUSE_MAP, 5, {"sBasemap", "desaturate", "desaturate_r", "desaturate_g", "desaturate_b"}, 0, { NULL }, "Diffuse Mapping"},
+	{ SDR_FLAG_DIFFUSE_MAP, 3, {"sBasemap", "desaturate", "desaturate_clr"}, 0, { NULL }, "Diffuse Mapping"},
 	{ SDR_FLAG_GLOW_MAP,	1, {"sGlowmap"}, 0, { NULL }, "Glow Mapping" },
 	{ SDR_FLAG_SPEC_MAP,	1, {"sSpecmap"}, 0, { NULL }, "Specular Mapping" },
 	{ SDR_FLAG_NORMAL_MAP,	1, {"sNormalmap"}, 0, { NULL }, "Normal Mapping" },
Index: graphics/gropengltnl.cpp
===================================================================
--- graphics/gropengltnl.cpp	(revision 11296)
+++ graphics/gropengltnl.cpp	(working copy)
@@ -715,9 +715,8 @@
 		}
 
 		vglUniform1iARB( opengl_shader_get_uniform("desaturate"), desaturate);
-		vglUniform1fARB( opengl_shader_get_uniform("desaturate_r"), gr_screen.current_color.red/255.0f);
-		vglUniform1fARB( opengl_shader_get_uniform("desaturate_g"), gr_screen.current_color.green/255.0f);
-		vglUniform1fARB( opengl_shader_get_uniform("desaturate_b"), gr_screen.current_color.blue/255.0f);
+		vglUniform3fARB( opengl_shader_get_uniform("desaturate_clr"), 
+			gr_screen.current_color.red/255.0f, gr_screen.current_color.green/255.0f, gr_screen.current_color.blue/255.0f);
 
 		gr_opengl_tcache_set(gr_screen.current_bitmap, tmap_type, &u_scale, &v_scale, render_pass);
 	
@@ -1353,6 +1352,7 @@
 					glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
 
 					opengl_shader_set_current(&GL_shader[sdr_index]);
+					GL_state.Texture.SetShaderMode(GL_TRUE);
 					Stream_buffer_sdr = sdr_index;
 
 					vglUniform1iARB(opengl_shader_get_uniform("baseMap"), 0);
@@ -1397,6 +1397,7 @@
 
 				if ( sdr_index != Stream_buffer_sdr ) {
 					opengl_shader_set_current(&GL_shader[sdr_index]);
+					GL_state.Texture.SetShaderMode(GL_TRUE);
 					Stream_buffer_sdr = sdr_index;
 
 					vglUniform1iARB(opengl_shader_get_uniform("baseMap"), 0);
@@ -1468,6 +1469,8 @@
 		vglDrawBuffers(2, buffers);
 	}
 	
+	GL_state.Texture.SetShaderMode(GL_FALSE);
+
 	GL_CHECK_FOR_ERRORS("end of render3d()");
 }
 
hunch2.patch (4,582 bytes)   

Swifty

2015-04-10 04:21

developer   ~0016636

Last hunch. Basically I make sure to disable all texture units in opengl_render_internal if we're not doing any texturing.

Goober5000

2015-04-11 03:50

administrator  

hunch2-callstack.txt (2,559 bytes)   
 	nvoglv32.dll!5b8223e2() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]	
 	nvoglv32.dll!5b838f57() 	
 	nvoglv32.dll!5b7ab00e() 	
 	nvoglv32.dll!5b79d64d() 	
 	nvoglv32.dll!5b79e637() 	
 	nvoglv32.dll!5b7981fe() 	
 	nvoglv32.dll!5b825282() 	
>	fs2_open_3_7_1-DEBUG.exe!opengl_texture_state::Enable(unsigned int tex_id=255)  Line 221 + 0x1f bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set_internal(int bitmap_handle=332757, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int tex_unit=0)  Line 1067	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_tcache_set(int bitmap_handle=332757, int bitmap_type=0, float * u_scale=0x0018ec14, float * v_scale=0x0018ec08, int stage=0)  Line 1110 + 0x19 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!opengl_aabitmap_ex_internal(int x=880, int y=624, int w=81, int h=15, int sx=0, int sy=0, int resize_mode=1, bool mirror=false)  Line 80 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_opengl_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 306 + 0x31 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!gr_aabitmap(int x=880, int y=624, int resize_mode=1, bool mirror=false)  Line 699 + 0x18 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int x=880, int y=624)  Line 853 + 0x17 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGauge::renderBitmap(int frame=332757, int x=880, int y=624)  Line 862	C++
 	fs2_open_3_7_1-DEBUG.exe!HudGaugeKills::render(float frametime=0.0083312988)  Line 2469	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_gauges(int cockpit_display_num=-1)  Line 1847 + 0x35 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!hud_render_all()  Line 1770 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_render_hud(camid cid={...})  Line 4265	C++
 	fs2_open_3_7_1-DEBUG.exe!game_frame(bool paused=false)  Line 4534 + 0x13 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_frame()  Line 4903 + 0x7 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_do_state(int state=2)  Line 6587	C++
 	fs2_open_3_7_1-DEBUG.exe!gameseq_process_events()  Line 409 + 0x14 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!game_main(char * cmdline=0x002e5534)  Line 7153 + 0x5 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x002e5534, int nCmdShow=10)  Line 7222 + 0x9 bytes	C++
 	fs2_open_3_7_1-DEBUG.exe!__tmainCRTStartup()  Line 324 + 0x35 bytes	C
 	fs2_open_3_7_1-DEBUG.exe!WinMainCRTStartup()  Line 196	C
 	kernel32.dll!7623338a() 	
 	ntdll.dll!77cf9f72() 	
 	ntdll.dll!77cf9f45() 	
hunch2-callstack.txt (2,559 bytes)   

Goober5000

2015-04-11 03:50

administrator  

hunch2-fs2_open.log (404,961 bytes)

Goober5000

2015-04-11 03:50

administrator   ~0016640

Crashed again. :( Logs attached as before.

Goober5000

2015-04-16 03:08

administrator   ~0016641

Assigning this bug to FSO 4 and untargeting from 3.7.2.

Goober5000

2015-05-20 05:08

administrator   ~0016710

Hmm. VS 2005 builds from both r11289 and 3.7.2 final exhibit the crash. But VS 2013 builds from both r11289 and 3.7.2 *do not* exhibit the crash.

This makes me think that this error *was* a compiler problem, except that the nightly builds I tested from r11289 to rule out this possibility (see #c16578) crashed as well. I've asked chief1983 what compiler he used to create the r11289 builds.

MageKing17

2015-05-20 05:13

developer   ~0016711

All Nightly builds prior to 2015-05-07 (935af40) were built with VS 2008 (since then, they've been built with VS 2013; see also http://www.hard-light.net/forums/index.php?topic=89681.msg1784993#msg1784993).

chief1983

2015-05-20 12:29

administrator   ~0016713

Yup, what he said. That was the cutover date, and I haven't looked back since.

Goober5000

2015-05-21 03:46

administrator   ~0016715

I'll test the two nightlies on either side of that date. Tomorrow though.

Goober5000

2015-05-22 04:05

administrator   ~0016716

Well, so much for that theory. Both 2015-05-06 (4d90765) and 2015-05-07 (935af40) crashed -- and there was even an attempt when 2015-05-06, the VS 2008 build, did *not* crash. This does not make any sense.

Guess I'll shove this ticket back under the bed then.

Goober5000

2015-12-19 23:06

administrator   ~0016805

Changing description. It's not widely reported anymore, but it has popped again for a couple people, and it certainly is insidious.

Goober5000

2022-06-11 02:13

administrator   ~0017144

This hasn't been reported in quite some time, so is probably no longer an issue.

Related Changesets

fs2open: trunk r11298

2015-04-08 21:27

Goober5000


Ported: N/A

Details Diff
related to Mantis 0003130 - don't create a VBO if we're not supposed to Affected Issues
0003130
mod - /trunk/fs2_open/code/graphics/gropengltnl.cpp Diff File

Issue History

Date Modified Username Field Change
2014-11-22 00:07 Goober5000 New Issue
2014-11-22 00:07 Goober5000 File Added: fs2_open-goober5000.log
2014-11-22 00:07 Goober5000 Status new => confirmed
2014-11-22 00:09 Goober5000 Additional Information Updated
2014-11-22 00:10 Goober5000 Description Updated
2014-11-22 00:15 Goober5000 File Deleted: fs2_open-goober5000.log
2014-11-22 00:15 Goober5000 File Added: fs2_open-mediavps.log
2014-11-22 00:16 Goober5000 File Added: fs2_open-nomediavps.log
2014-11-22 00:16 Goober5000 Description Updated
2014-11-22 01:20 MageKing17 Note Added: 0016390
2014-11-22 18:20 Goober5000 Note Added: 0016391
2014-11-22 18:20 Goober5000 Note Edited: 0016391
2014-11-22 18:22 Goober5000 Note Edited: 0016391
2014-11-22 18:31 Goober5000 Note Added: 0016392
2014-11-22 18:31 Goober5000 File Added: crash error.jpg
2014-11-22 18:31 Goober5000 File Added: call stack.txt
2014-11-22 19:45 Goober5000 File Added: MVP 2014 patches.zip
2014-11-22 19:45 Goober5000 Note Added: 0016393
2014-11-22 21:36 Goober5000 Note Added: 0016394
2014-11-23 16:24 m_m Note Added: 0016395
2014-11-23 17:08 Goober5000 Note Added: 0016396
2014-11-23 17:50 m_m Note Added: 0016397
2014-11-23 18:38 MageKing17 Note Added: 0016398
2014-11-23 19:30 Goober5000 File Added: call stack 2.txt
2014-11-23 19:30 Goober5000 File Added: call stack 3.txt
2014-11-23 19:31 Goober5000 File Added: fs2_open 3.log
2014-11-23 20:15 Goober5000 File Added: fs2_open 4.log
2014-11-23 20:15 Goober5000 File Added: call stack 4.txt
2014-11-23 20:15 Goober5000 Note Added: 0016399
2014-12-14 19:39 chief1983 Product Version 3.7.2 => 3.7.2 RC4
2014-12-19 15:03 chief1983 Note Added: 0016420
2014-12-20 21:29 Goober5000 Note Added: 0016422
2014-12-20 21:34 chief1983 Note Added: 0016423
2014-12-20 22:29 Goober5000 Note Added: 0016424
2014-12-20 22:36 MageKing17 Note Added: 0016425
2014-12-20 22:53 chief1983 Note Added: 0016426
2014-12-21 00:55 MageKing17 Note Added: 0016427
2014-12-21 02:45 Goober5000 Note Added: 0016428
2014-12-21 04:23 chief1983 Note Added: 0016429
2015-01-03 21:59 z64555 Note Added: 0016435
2015-01-03 22:00 z64555 Note Edited: 0016435
2015-01-03 22:02 z64555 Note Edited: 0016435
2015-01-03 22:04 Goober5000 Note Added: 0016436
2015-01-03 22:49 Goober5000 Note Added: 0016437
2015-01-03 22:49 Goober5000 Note Edited: 0016437
2015-01-04 02:07 Goober5000 File Added: call stack 5.txt
2015-01-04 07:08 niffiwan Note Added: 0016439
2015-01-04 07:08 niffiwan Note Edited: 0016439
2015-01-04 07:38 Goober5000 Note Added: 0016441
2015-01-04 07:54 MageKing17 Note Added: 0016443
2015-01-05 05:31 Goober5000 File Added: call stack 6.txt
2015-01-05 05:33 Goober5000 Note Added: 0016444
2015-01-05 05:33 Goober5000 Note Edited: 0016444
2015-01-05 07:30 MageKing17 File Added: hud.cpp.patch
2015-01-05 07:30 MageKing17 Note Added: 0016445
2015-01-05 08:31 MageKing17 File Added: gropengltexture.cpp.patch
2015-01-05 08:32 MageKing17 Note Edited: 0016445
2015-01-07 22:04 MageKing17 File Added: smother_with_error_checking.patch
2015-01-09 15:56 Goober5000 Note Added: 0016448
2015-01-11 03:43 Goober5000 File Added: call_stack-2015-01-10.txt
2015-01-11 03:43 Goober5000 File Added: fs2_open-2015-01-10.log
2015-01-11 03:44 Goober5000 Note Added: 0016449
2015-01-11 03:51 MageKing17 Note Added: 0016450
2015-01-11 22:30 Goober5000 Note Added: 0016451
2015-01-11 22:39 MageKing17 Note Added: 0016452
2015-01-11 22:42 chief1983 Note Added: 0016453
2015-01-18 02:30 Goober5000 Note Added: 0016454
2015-01-29 12:44 niffiwan Note Added: 0016466
2015-01-29 21:33 niffiwan Note Edited: 0016466
2015-02-01 07:59 Goober5000 Note Added: 0016467
2015-02-07 17:04 Inglonias Note Added: 0016475
2015-02-07 17:20 Inglonias Note Edited: 0016475
2015-02-07 17:52 Goober5000 Note Added: 0016476
2015-02-08 22:09 niffiwan Note Added: 0016477
2015-02-08 22:31 niffiwan Note Added: 0016478
2015-02-09 02:04 Goober5000 File Added: bmpman_entry.txt
2015-02-09 02:04 Goober5000 Note Added: 0016479
2015-02-09 02:05 Goober5000 Note Edited: 0016479
2015-02-09 02:22 niffiwan Note Edited: 0016477
2015-02-09 02:27 MageKing17 Note Added: 0016480
2015-02-09 02:30 niffiwan Note Edited: 0016478
2015-02-09 04:42 Goober5000 Note Added: 0016482
2015-02-09 04:52 niffiwan Note Added: 0016483
2015-02-09 05:23 MageKing17 Note Added: 0016485
2015-02-09 07:22 Goober5000 Note Added: 0016486
2015-02-09 07:23 Goober5000 Note Edited: 0016486
2015-02-09 10:21 niffiwan Note Added: 0016487
2015-02-09 10:22 niffiwan Note Edited: 0016487
2015-02-09 10:23 niffiwan Note Edited: 0016487
2015-02-09 10:24 niffiwan Note Edited: 0016487
2015-02-09 10:42 niffiwan Note Edited: 0016487
2015-02-10 03:00 Goober5000 Note Added: 0016494
2015-02-19 01:28 MageKing17 Note Added: 0016498
2015-02-19 03:00 Goober5000 Note Added: 0016499
2015-02-19 18:00 MageKing17 Note Added: 0016500
2015-02-19 18:10 chief1983 Note Added: 0016501
2015-02-20 01:22 niffiwan Note Added: 0016502
2015-02-21 04:51 Goober5000 Note Added: 0016503
2015-02-22 21:03 LotF Note Added: 0016505
2015-02-23 01:15 Goober5000 Note Added: 0016509
2015-02-23 01:16 Goober5000 File Added: bm_bitmaps watch.txt
2015-02-23 03:41 MageKing17 Note Added: 0016510
2015-02-23 04:42 Goober5000 Note Added: 0016511
2015-02-27 00:56 MageKing17 File Added: disable_reuse.patch
2015-02-27 00:57 MageKing17 Note Added: 0016515
2015-03-02 07:01 Goober5000 Note Added: 0016523
2015-03-02 07:40 MageKing17 Note Added: 0016524
2015-03-04 03:14 MageKing17 File Added: 3130.patch
2015-03-04 03:17 MageKing17 Note Added: 0016533
2015-03-04 03:18 MageKing17 File Deleted: 3130.patch
2015-03-04 03:18 MageKing17 File Added: 3130.patch
2015-03-04 03:45 MageKing17 File Deleted: 3130.patch
2015-03-04 03:45 MageKing17 File Added: 3130.patch
2015-03-04 05:45 Goober5000 File Added: call stack wo dummy.txt
2015-03-04 05:45 Goober5000 File Added: call stack w dummy.txt
2015-03-04 05:46 Goober5000 File Added: call stack w dummy and kills disabled.txt
2015-03-04 05:46 Goober5000 File Added: different crash call stack.txt
2015-03-04 05:46 Goober5000 File Added: different crash fs2_open.7z
2015-03-04 05:47 Goober5000 Note Added: 0016534
2015-03-04 06:06 MageKing17 File Deleted: 3130.patch
2015-03-04 06:06 MageKing17 File Added: 3130.patch
2015-03-04 06:16 MageKing17 Note Added: 0016535
2015-03-05 08:29 MageKing17 File Added: redundancy.patch
2015-03-05 08:31 MageKing17 Note Added: 0016536
2015-03-09 15:07 chief1983 Note Added: 0016539
2015-03-09 16:28 Inglonias Note Added: 0016540
2015-03-09 16:28 Inglonias Note Edited: 0016540
2015-03-09 16:34 chief1983 Note Added: 0016541
2015-03-09 16:36 Inglonias Note Added: 0016542
2015-03-09 16:37 MageKing17 Note Added: 0016543
2015-03-09 16:43 Inglonias Note Added: 0016544
2015-03-09 17:01 Inglonias Note Added: 0016545
2015-03-10 03:05 Goober5000 Note Added: 0016546
2015-03-10 04:23 Goober5000 File Added: callstack w redundancy.txt
2015-03-10 04:23 Goober5000 File Added: units.txt
2015-03-10 04:28 Goober5000 Note Added: 0016547
2015-03-10 04:37 MageKing17 Note Added: 0016548
2015-03-10 04:38 MageKing17 Note Edited: 0016548
2015-03-10 04:45 MageKing17 Note Edited: 0016548
2015-03-10 05:07 MageKing17 Note Edited: 0016548
2015-03-10 05:46 Inglonias Note Added: 0016549
2015-03-10 05:46 Inglonias Note Edited: 0016549
2015-03-11 00:39 Goober5000 Note Added: 0016550
2015-03-11 01:11 Goober5000 Note Added: 0016551
2015-03-11 01:12 Goober5000 Note Added: 0016552
2015-03-11 02:12 MageKing17 Note Added: 0016553
2015-03-11 03:51 MageKing17 File Added: hudtarget.cpp.patch
2015-03-11 04:04 MageKing17 Note Added: 0016554
2015-03-15 06:15 Goober5000 Note Added: 0016556
2015-03-15 06:16 Goober5000 File Added: enabling triangles.txt
2015-03-15 06:56 Goober5000 Note Added: 0016557
2015-03-15 06:57 Goober5000 Note Edited: 0016557
2015-03-15 08:06 MageKing17 Note Added: 0016558
2015-03-16 04:24 Goober5000 Note Added: 0016559
2015-03-16 04:29 Goober5000 Note Edited: 0016559
2015-03-16 04:33 MageKing17 Note Added: 0016560
2015-03-16 15:10 Goober5000 Note Added: 0016561
2015-03-16 16:44 MageKing17 Note Added: 0016562
2015-03-16 16:59 chief1983 Note Added: 0016563
2015-03-17 02:07 Goober5000 Note Added: 0016564
2015-03-22 07:16 MageKing17 Note Added: 0016571
2015-03-23 06:08 Goober5000 File Added: swifty.patch
2015-03-23 06:12 Goober5000 Note Added: 0016572
2015-03-27 01:32 Goober5000 Note Added: 0016578
2015-03-27 13:49 chief1983 Note Added: 0016579
2015-03-28 02:23 Goober5000 Note Added: 0016582
2015-03-28 12:54 chief1983 Note Added: 0016584
2015-03-28 18:57 Goober5000 Note Added: 0016585
2015-03-29 03:47 chief1983 Note Added: 0016586
2015-03-29 04:41 Goober5000 Note Added: 0016587
2015-03-29 08:11 The_E Note Added: 0016588
2015-03-29 16:38 m_m Note Added: 0016589
2015-03-29 17:16 Goober5000 Note Added: 0016590
2015-03-29 21:45 Swifty Note Added: 0016591
2015-03-29 21:46 Swifty Note Edited: 0016591
2015-03-29 21:51 Swifty Note Edited: 0016591
2015-03-30 03:02 Goober5000 Note Added: 0016592
2015-03-30 03:49 Goober5000 Note Added: 0016593
2015-04-02 04:43 Goober5000 Note Added: 0016597
2015-04-07 19:09 chief1983 Note Added: 0016608
2015-04-08 04:28 Goober5000 Note Added: 0016620
2015-04-08 05:42 Goober5000 Note Added: 0016621
2015-04-08 07:49 Swifty File Added: desaturate_fix.patch
2015-04-08 07:54 Swifty Note Added: 0016622
2015-04-09 01:05 Goober5000 Changeset attached => fs2open trunk r11298
2015-04-09 03:10 Goober5000 File Added: desaturate-callstack.txt
2015-04-09 03:11 Goober5000 File Added: desaturate-fs2_open.log
2015-04-09 03:13 Goober5000 Note Added: 0016627
2015-04-09 03:13 Goober5000 Note Edited: 0016627
2015-04-10 02:29 Goober5000 Note Added: 0016632
2015-04-10 03:01 Swifty File Added: shader_mode_hunch.patch
2015-04-10 03:06 Swifty Note Added: 0016634
2015-04-10 04:13 Goober5000 File Added: hunch-callstack.txt
2015-04-10 04:13 Goober5000 File Added: hunch-fs2_open.log
2015-04-10 04:13 Goober5000 Note Added: 0016635
2015-04-10 04:17 Swifty File Added: hunch2.patch
2015-04-10 04:21 Swifty Note Added: 0016636
2015-04-10 06:44 The_E Priority urgent => normal
2015-04-10 06:44 The_E Severity block => major
2015-04-11 03:50 Goober5000 File Added: hunch2-callstack.txt
2015-04-11 03:50 Goober5000 File Added: hunch2-fs2_open.log
2015-04-11 03:50 Goober5000 Note Added: 0016640
2015-04-16 03:08 Goober5000 Note Added: 0016641
2015-04-16 03:08 Goober5000 Assigned To => FSO 4
2015-04-16 03:08 Goober5000 Resolution open => suspended
2015-04-16 03:08 Goober5000 Target Version 3.7.2 =>
2015-05-20 05:08 Goober5000 Note Added: 0016710
2015-05-20 05:09 Goober5000 Relationship added related to 0000001
2015-05-20 05:13 MageKing17 Note Added: 0016711
2015-05-20 12:29 chief1983 Note Added: 0016713
2015-05-21 03:46 Goober5000 Note Added: 0016715
2015-05-22 04:05 Goober5000 Note Added: 0016716
2015-12-19 23:06 Goober5000 Note Added: 0016805
2015-12-19 23:06 Goober5000 Summary The widely reported beam crash bug => The insidious beam crash bug
2022-06-11 02:13 Goober5000 Status confirmed => closed
2022-06-11 02:13 Goober5000 Resolution suspended => unable to reproduce
2022-06-11 02:13 Goober5000 Note Added: 0017144