A program I have been working on for years has suddenly developed a bug in it and at a certain point, it is just terminating and not giving me any runtime errors or any error of any kind. It's just running.... running... running... then BAM - GONE, no explanation.... %errorlevel% is -1073741819

I have been trying to track it down by putting writeln's in my code before and after the section that is causing me the problem, but without the diagnostic information I normally get, this is very tedious. I am at a point now where I've determined that it's something in a data processing loop that has hundreds of case statements... If I try to writeln all so I can see what's the last thing it wrote to the console before it crashed, it takes so long to run it's going to take me a very long time. If I had the runtime error or some kind of information, I would have fixed this in minutes, but doing it this way has already taken me hours.

I wrote a sample program that generates a runtime error on purpose and it's working fine... I get the normal runtime error output I always do telling me what the problem is and what line number it's on.. etc...

The strange thing about this bug is that I can run the program on the same computer successfully in my development directory but it crashes when it's in another installation I have for pre-release testing... so it's not crashing when I run it from the FPC text IDE.. but when I move the executable over to my pre-release testing directory, then it is crashing like this with no indication of anything except the strange errorlevel being set.

Has anyone encountered anything like this before or know how I can make sure I always get the maximum amount of debugging info when my program crashes?

Hi,

James Richters wrote

Has anyone encountered anything like this before or know how I can make sure I always get the maximum amount of debugging info when my program crashes?

Is it a subthreaded app?

The only case when I noticed something similar (under Linux though), when a certain subthread throws an exception, it just silently disappears without any further handling. It doesn't throw any exception, unless you wrap the entire Execute method in a try-except.

(Sidenote: I've been pondering for a while if I should report this as a bug. I think the RTL should put a try-except around there, to show a stacktrace on unhandled exceptions, just like the main thread dying does, but who knows which Delphi de-facto standard behavior would that violate, so meh...)

In Linux/Darwin (on x64/ARM at least), only the thread causing the problem dies, no clue what happens under Windows. Maybe this helps.

Charlie

Karoly Balogh (Charlie/SGR) schrieb am Mi., 15.
Mai 2019, 15:25:

That is already the case at least for TThread descendants as can be seen in rtl/unix/tthread.inc, ThreadFunc. This is needed for the FatalException field.

One could argue whether the BeginThread API should protect the function as well though... 🤷‍♀️

Regards,
Sven

It's a simple single thread console app. I found my problem... years ago I implemented a batch file to run my program in the test environment to help be with debugging... and what it does is redirect the errors to a file so that if flashed by real quick, I would be able to just look at the file. Then I just echo the file to the screen, and if I detect an error, I also pause so I can see it. This a common solution to the windows limitation of not be capable directing STDERR to console AND to a file.

Well the file wasn't reporting the error and it wasn't on the screen... it looked like a normal exit, BUT it was actually giving me the proper report... unfortunately the error was the one thing that my batch file could not possibly display.... EInOutError: Disk Full DOH!!! With the disk full my log file could only show up to but not including the error... because it could not write anymore on a full disk... I still don't have a great solution for this... I see methods of implementing something like a Tee function on windows, but the problem is I don't want ALL the output to go to the log, I only want STDERR to go to the log file.... and the screen... not my output I am sending with the CRT unit that sends colored text for various purposes. This is such a pain with windows to accomplish this seemingly simple task. Anyway I know what the problem is and can put in something to detect it. Maybe I will just check if the errorlevel is negative and if so write a suggestion to the screen that disk full may have caused this and then pause.... since I can't necessarily write anything to the file.

Does anyone know what the errorlevel for EInOutError: Disk Full is -1073741819, (I'm not sure it's always that number... ) is this on purpose?, or a bug?, or a side effect of the disk being full so it can't generate the correct error code? if it was a normal errorcode I would have got that on my screen but since it's less than zero it got treated like a normal exit.... I did fix my batch file to treat anything less than zero as an error..... so it doesn't really matter, I just didn't know they could be negative, but I'm curious why this strange errorlevel.

Jim

Windows represents exception codes as an unsigned int. The error -1073741819 is actually0xC0000005.

This represents some form of access violation, usually associated with trying to write to freed memory,double freeing memory etc. If the stack is involved/corrupted then a trackback and useful information would be difficult.

Whereabouts down the line a disk full translates into an access violation is difficult to say, but it results in a mess to say the least.

Regards,

Gary.

Isn't that negative number 0xC0000005 in hex? If that's the case, it's an Access Violation and not Disk Full.

Jeff.

On Wed, May 15, 2019 at 11:44 AM James Richters <

Hi,

Hmm, I see, indeed. Should have checked the source code, but I never cared... -.-' Well, the stacktrace is stilly only printed on DEBUG_MT, if i'm correct?, so from the developer's perspective, the thread is still dying 'silently', and sometimes it's hard to identify if your thread went away or just blocked, when seeing an issue... Anyway, not important and unrelated here.

Charlie

Karoly Balogh (Charlie/SGR) schrieb am Mi., 15.
Mai 2019, 18:40:

It won't terminate quietly, because FatalException will be set in that case (of course assuming that FreeOnTerminate is false). This means that the user must actively check whether a thread crashed. But that would be the necessary with any other mechanism as well, cause we don't want to automatically print a stack trace as the developer might not want that or it might not even be possible (e.g. writing to StdOut or StdErr would not be possible on Windows for GUI applications).

Though maybe one could add an event that is triggered when an exception had been raised. That would give the developer the opportunity to handle the exception when it occurred.

Regards,
Sven

Seeing that the FatalException property exists, an event

Property OnFatalException : TNotifyEvent;

seems indeed appropriate.

Michael.

Once I fixed my batch file I am getting exactly this:

An unhandled exception occurred at $004E4B4C:

EInOutError: Disk Full

$004E4B4C GETDATA, line 19078 of pastep.pas

$004E9695 GETAFILE, line 19997 of pastep.pas

$004EB74E GETALIPSE, line 20159 of pastep.pas

$004E6884 LOADIT, line 19159 of pastep.pas

$0041B86A main, line 4155 of i:/programming/gcode/mill/promill.pas

Error Code: -1073741819

And yes my drive really is full.

I am able to do a jump in my batch file based on the negative error code and send it to where all the other error conditions go.

James

For anyone who didn’t see in in my other message.. the only reason I didn’t see the debug info before was because I was redirecting stderr to a file then echoing the file to the screen.. but with a full disk, no more could be written into my log file, therefore the file ended just before the error.

It’s the one case the logging stderr to a file the echoing the file to console could not work. Widnows doesn’t have a really good way to send output to the console and a file at the same time.

In combination with this the errorcode being displayed as a negative number put it into the category of “things zero or less” which made my batch file treat it as a normal exit.

It was my batch file that was failing to function correctly.

James