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.
On 15/05/2019 16:43, James Richters wrote:
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
-----Original Message-----
From: fpc-pascal <fpc-pascal-boun...@lists.freepascal.org> On Behalf Of Karoly
Balogh (Charlie/SGR)
Sent: Wednesday, May 15, 2019 9:17 AM
To: FPC-Pascal users discussions <fpc-pascal@lists.freepascal.org>
Subject: Re: [fpc-pascal] unexpected termination with no errors
Hi,
On Wed, 15 May 2019, 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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
