DEBUGGING without DEBUG

[r00k]

I've noticed that if i run a shortcut like 'C:\Users\Admin\Desktop\qrack2.010\glQrack.exe' sometimes the SetUnhandledExceptionFilter gets tripped. ONLY using that shortcut and sometimes with or without using a parameter.
At first i thought maybe there was a commandline bug, or mem init crapping or video but, just clicking the .exe no problem, clicking the above shortcut with no parameters, crash.

So the weird thing is that if i use the same shortcut above but goto advance and select "run as an admin" poof no more crash any suggestions?

Also I cant get it to crash in debug mode only the release...

[frag.machine]

Try setting the working folder/directory in the shortcut properties.

[r00k]

Ya i have the "start in" (windows 7) portion in that shortcut set.

I erased the shortcut and created another.

I forgot to mention that I put the shortcut in the start menu, there it crashes every time without a command line parameter.

if I supply a command line parameter (anything), it is erratic when it will crash.

Though if I have the SAME shortcut in the same folder as the exe, or even on my desktop no crash. Weird...

[mh]

[r00k]

[mh]

It's specifically the "lpCmdLine[-1] = 0;" part - that's stomping over some random memory allocated during CRT startup. I'm not certain what the intention is there - I think the idea is to isolate the executable name? - but I'm not seeing any indication that the executable name precedes lpCmdLine in memory in my MSDN. GetModuleFileName will do the same job but without any tricksy stuff.

[r00k]

[r00k]

Looking at the quake.rc, i found that Joesef had changed it to only carry the command 'stuffcmds', which gett he invalid pointer when there is no command line parameter. Not sure why this only effects starting the engine via a shortcut instead of double clicking the .exe itself. But without that quake.rc it works, adding +stuffcmds to the shortcut as the only parameter, crashes the engine cold. Itt was a bug in stuffcmds :O

[Knightmare]

I've had a vaguely similar problem when compiling KMQ2 under newer Visual Studio versions (2003 and all later versions) and not under under VC6, which I have used for a long time. Debug builds work fine, but release builds always crash on startup. I used the process of elimination to find out it was the option to generate debug info at the link stage that was responsible for crashing or not crashing. This semi-release build option makes the executable about 100KB larger than a normal release build (1.37Mb vs. 1.27 MB).

I thought it was most likely the old static libraries I was linking with, so I recompiled all of them with VS2008. This fixed nothing. I found by adding debug outputs and using logfile 2 that adding calls to Com_DPrintf at certain points would temporarily prevent the crashes, but significant changes that result in different executable size (or just changes to code optimization settings) would cause it to crash on startup again. Has anyone else had a crash that came down to the linker debug setting under newer Visual Studio versions?

[revelator]

been a while since i used vs2005 / 2008 but yeah i remember some weirdness in regard to debug settings. nowadays i mostly use codeblocks with mingw64.

[Knightmare]

Just tried it again since I added PNG support (addition of libpng). The old Com_Dprintf additions don't prevent the crash anymore, and the crash now happens somewhere in the cinematic code (I added Com_Dprintf outputs before each function call). It happens in slightly different places with each build, too, so it might be random.

[Baker]

[revelator]

aye clang is somewhat nice though it still lacks some understanding of C++ but its getting better. the llvm backend also has some nice code analysis tools.
btw do the functions you encounter these crashes in use the old vsprintf ? asking cause i know later gfx drivers croak a lot unless you use string safe printbuffers like _vsnprintf.

If you use mingw my latest uploaded mingw compiler got the dragonegg llvm compiler as a plugin (same options as clang) you can enable the pluging by doing CPPFLAGS="-fplugin=dragonegg-cc1".
feel free to "ab"use it

[Knightmare]

I switched everything to _vsnprintf 2.5 years ago when the driver-induced crashes first started happening.

EDIT: The crash happens after the renderer init, when a driver-related crash like that would happen. The main menu and its images have always already loaded.
It usually happens when it's attempting to load a cinematic, or sometimes drops to console after that when loading the map for a demo (Bad brushside texinfo error). These crashes and errors seem to be centered around functions that use LittleLong or LittleShort. Maybe the linker is screwing up the byte order functions?

[revelator]

should have guessed but ya newer know bit hard to debug when it works in debug mode :S one thing you could try is running cppcheck on the source and take note if it suggests fixing something. i use that tool a lot and it saved me quite some headaches over time. warning its slower than molasses though.