|
|
|
|
|
|
|
|
|
|
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? |
|
|
|
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.
|
|
|
|
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. |
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
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. |
|
|
|
Updating the NVIDIA drivers did not solve the crash. |
|
|
|
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? |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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 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 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()
|
|
|
|
More logs attached. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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"). |
|
|
|
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. |
|
|
|
Null result on a GTX 580; sounds like this problem only affects 600-series and later cards. |
|
|
|
Mine is a Quadro K2100M, if that helps. |
|
|
|
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
|
|
|
|
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." |
|
|
|
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.
|
|
|
|
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()
|
|
|
|
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?
|
|
|
|
If you can whip up a test mission, I'll test it out. I've been using Exodus (sm3-06) and applying various tweaks. |
|
|
|
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.) |
|
|
|
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()
|
|
|
|
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.
|
|
|
|
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()
|
|
|
|
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.
|
|
|
|
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) )
|
|
|
|
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) )
|
|
|
|
I haven't had a chance to test the patch yet, but hopefully I can do so this evening. |
|
|
|
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()
|
|
|
|
|
|
|
|
Or the following evening. >.> Crashed again in the same place. New log and stack trace attached. |
|
|
|
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? |
|
|
|
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. |
|
|
|
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? |
|
|
|
Looks like it. http://www.nvidia.com/download/driverResults.aspx/80141/en-us 341.21, on December 5. |
|
|
|
I installed the driver update. Crash still occurs. |
|
|
|
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.
|
|
|
|
Updated the driver again. Still crashes. |
|
|
|
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?
|
|
|
|
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. |
|
|
|
@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.
|
|
|
|
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
|
|
|
|
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
|
|
|
|
@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.
|
|
|
|
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? |
|
|
|
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. |
|
|
|
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. |
|
|
|
"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. |
|
|
|
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."
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
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? |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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) |
|
|
|
K. I'll give that a try on Saturday. |
|
|
|
No issues with my GeForce GTX 660 Ti (Vendor: MSI, Driver: nvlddmkm 9.18.13.3788 (ForceWare 337.88) / Vista 64bit) |
|
|
|
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. |
|
|
|
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
|
|
|
|
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? |
|
|
|
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. |
|
|
|
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;
|
|
|
|
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. |
|
|
|
Crashed again, same place. Same bitmap handle, in fact. (Yes, I double-checked that your patch had been applied.) |
|
|
|
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. |
|
|
|
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). |
|
|
|
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 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 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()
|
|
|
|
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()
|
|
|
|
|
|
|
|
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.) |
|
|
|
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
|
|
|
|
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. |
|
|
|
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;
}
|
|
|
|
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. |
|
|
|
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? |
|
|
|
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.
|
|
|
|
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? |
|
|
|
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. |
|
|
|
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! |
|
|
|
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) |
|
|
|
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. |
|
|
|
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. |
|
|
|
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()
|
|
|
|
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
|
|
|
|
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.) |
|
|
|
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.
|
|
|
|
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!
|
|
|
|
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. |
|
|
|
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. |
|
|
|
(Note that usually HUD_OBJECT_KILLS is two spaces below HUD_OBJECT_TARGET_TRI, not one space.) |
|
|
|
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). |
|
|
|
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);
|
|
|
|
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().) |
|
|
|
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... |
|
|
|
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()
|
|
|
|
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?)
|
|
|
|
"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) ) { |
|
|
|
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.
|
|
|
|
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. |
|
|
|
Did you get anything out of the "enabling triangles.txt" stack trace? |
|
|
|
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. |
|
|
|
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. |
|
|
|
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? |
|
|
|
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? |
|
|
|
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();
|
|
|
|
Alas, no effect. It crashes in the same place. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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? |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
@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. |
|
|
|
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.
|
|
|
|
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. |
|
|
|
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. |
|
|
|
Just a quick update to say that progress is being made. We have some debugging callbacks running in the OpenGL functions now. |
|
|
|
All right, progress is nice but seriously, we need like daily updates at this point to keep justifying waiting on this bug. |
|
|
|
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. |
|
|
|
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);
|
|
|
|
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. |
|
|
|
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()
|
|
|
|
|
|
|
|
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.
|
|
|
|
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()");
}
|
|
|
|
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? |
|
|
|
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()
|
|
|
|
|
|
|
|
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()");
}
|
|
|
|
Last hunch. Basically I make sure to disable all texture units in opengl_render_internal if we're not doing any texturing. |
|
|
|
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()
|
|
|
|
|
|
|
|
Crashed again. :( Logs attached as before. |
|
|
|
Assigning this bug to FSO 4 and untargeting from 3.7.2. |
|
|
|
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. |
|
|
|
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). |
|
|
|
Yup, what he said. That was the cutover date, and I haven't looked back since. |
|
|
|
I'll test the two nightlies on either side of that date. Tomorrow though. |
|
|
|
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. |
|
|
|
Changing description. It's not widely reported anymore, but it has popped again for a couple people, and it certainly is insidious. |
|
|
|
This hasn't been reported in quite some time, so is probably no longer an issue. |
|
