ocide crashes on opening cwa
GitMensch opened this issue · comments
Using the latest CI build (MINGW64) I've opened an existing cwa. It gets opened as workspace, the contained projects are load, all last-opened windows are opened, code is analyzed, ocide gets unresponsive and exits without any message.
After this happens there's still one process hogging on the generated .ods: occpr.exe with complete invocation:
"C:\dev\OrangeC\bin\occpr.exe" /c /C+? /Wd /9 /E100 -! "-oC:\dev\gnucobol\build_windows\ocide\GnuCOBOL.ods" /P94219640 "/I;C:\dev\gnucobol\build_windows\ocide\..\..;C:\dev\gnucobol\build_windows\ocide\..;" "C:\dev\gnucobol\libcob\common.c"
I assume there is a log file which I just couldn't find that tells me why OCIDE chrashed, is it?
it seemed ok a couple of weeks ago when I was testing that other issue... will look again.
There is a hook at the application level to catch exceptions and display a dialog similar to crash dumps you see for console programs. But as far as I could tell at some point microsoft got tired of programs crashing and put exception catch blocks around each call to window procedures... from what I could tell when I first saw this windows silently aborts the call to the procedure and leaves the program in some indeterminate state. Sometimes the indeterminate state is bad enough that the program exits but not always.
Console programs at least allow us to catch the exception properly (again at the application level) which is where you see the crash dumps output by the Orange C runtime. But most toolchains don't intercept that and recent versions of windows will silently abort on those exceptions too if uncaught. You see that sometimes if the first built version of the tools crashes (before it is built with itself) -- such crashes usually return a large negative return code which you can see in the omake logs. I find it very annoying as a developer since it isn't at all obvious when programs crash any more unless they have a gui that goes away..
The debugger will catch all this but I don't always run in the debugger while developing...
The return level does only apply if the program chrashes during startup, this doesn't happen here.
In nearly all cases it is possible to register a "final" error handler that Windows will invoke which will allow to dump the error and track to a file.
Is there a log file available (if yes, where)? Can I somehow let OCIDE run in debug-mode without compiling OrangeC myself? [it would be really useful to provide an artifact with debug symbols included...]
well last time I checked orangec runtime always hooks the final error handler, but something 'catches' exceptions before it gets called... I will check again...
ocppr hanging isn't so good, that is the program that does the code completion analysis. I will look into it...
opening a new issue for your request to have a debug build.
I fixed some problems in the code completion analysis engine; this crash/hang thing is an ongoing problem so tomorrow I will look into out how to put tests for this into the build...
well i figured out tonite that occpr is currently ok for valid source files. But if I write a program to randomly skip bytes in a valid source file and create a new source file with the bytes skipped, I can create new source files which sometimes crash both OCC and OCCPR when processed. That is kind of a big deal for OCCPR because it is not supposed to always have valid sources... and OCC should also be nicer than that... so I'm going to take a detour this weekend and concentrate on this issue instead of continuing with the main work of the milestone.
I don't know if that will take care of the issue with OCIDE crashing though... I'm mostly focussing on your comment that occpr just hung around indefinitely right now.
I did add a configuration with PDBs to appveyor in case you feel like trying it.
after fixing a bunch of crash conditions, I added a new build configuration to test occpr... it randomly generates a bunch of syntax errors then compiles the resulting files.
@GitMensch : I haven't been able to duplicate a crash in OCIDE itself. Is this still an issue?