unexpected termination with no errors

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

unexpected termination with no errors

Zaaphod
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?    
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: unexpected termination with no errors

Karoly Balogh (Charlie/SGR)
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: unexpected termination with no errors

Free Pascal - General mailing list
Karoly Balogh (Charlie/SGR) <[hidden email]> schrieb am Mi., 15. Mai 2019, 15:25:
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...)

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 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: unexpected termination with no errors

Zaaphod
In reply to this post by Karoly Balogh (Charlie/SGR)
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 <[hidden email]> On Behalf Of Karoly Balogh (Charlie/SGR)
Sent: Wednesday, May 15, 2019 9:17 AM
To: FPC-Pascal users discussions <[hidden email]>
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  -  [hidden email] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: unexpected termination with no errors

Gary Doades
Windows represents exception codes as an unsigned int. The error -1073741819 is actually 0xC0000005.
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 [hidden email] On Behalf Of Karoly Balogh (Charlie/SGR)
Sent: Wednesday, May 15, 2019 9:17 AM
To: FPC-Pascal users discussions [hidden email]
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  -  [hidden email] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: unexpected termination with no errors

DaWorm
In reply to this post by Zaaphod
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Karoly Balogh (Charlie/SGR)
Sent: Wednesday, May 15, 2019 9:17 AM
To: FPC-Pascal users discussions <[hidden email]>
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  -  [hidden email] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: unexpected termination with no errors

Karoly Balogh (Charlie/SGR)
In reply to this post by Free Pascal - General mailing list
Hi,

On Wed, 15 May 2019, Sven Barth via fpc-pascal wrote:

>> (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...)
>
> 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. 

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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: unexpected termination with no errors

Free Pascal - General mailing list
Karoly Balogh (Charlie/SGR) <[hidden email]> schrieb am Mi., 15. Mai 2019, 18:40:
Hi,

On Wed, 15 May 2019, Sven Barth via fpc-pascal wrote:

>> (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...)
>
> 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. 

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.

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 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: unexpected termination with no errors

Michael Van Canneyt


On Thu, 16 May 2019, Sven Barth via fpc-pascal wrote:

> Karoly Balogh (Charlie/SGR) <[hidden email]> schrieb am Mi., 15.
> Mai 2019, 18:40:
>
>> Hi,
>>
>> On Wed, 15 May 2019, Sven Barth via fpc-pascal wrote:
>>
>>>> (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...)
>>>
>>> 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.
>>
>> 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.
>>
>
> 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.

Seeing that the FatalException property exists, an event

Property OnFatalException : TNotifyEvent;

seems indeed appropriate.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: unexpected termination with no errors

Zaaphod
In reply to this post by Gary Doades

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

 

From: fpc-pascal <[hidden email]> On Behalf Of Gary Doades
Sent: Wednesday, May 15, 2019 12:11 PM
To: [hidden email]
Subject: Re: [fpc-pascal] unexpected termination with no errors

 

Windows represents exception codes as an unsigned int. The error -1073741819 is actually 0xC0000005.
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 [hidden email] On Behalf Of Karoly Balogh (Charlie/SGR)
Sent: Wednesday, May 15, 2019 9:17 AM
To: FPC-Pascal users discussions [hidden email]
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  -  [hidden email] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: unexpected termination with no errors

Zaaphod

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

 

From: fpc-pascal <[hidden email]> On Behalf Of James Richters
Sent: Thursday, May 16, 2019 7:31 AM
To: 'FPC-Pascal users discussions' <[hidden email]>
Subject: Re: [fpc-pascal] unexpected termination with no errors

 

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

 

From: fpc-pascal <[hidden email]> On Behalf Of Gary Doades
Sent: Wednesday, May 15, 2019 12:11 PM
To: [hidden email]
Subject: Re: [fpc-pascal] unexpected termination with no errors

 

Windows represents exception codes as an unsigned int. The error -1073741819 is actually 0xC0000005.
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 [hidden email] On Behalf Of Karoly Balogh (Charlie/SGR)
Sent: Wednesday, May 15, 2019 9:17 AM
To: FPC-Pascal users discussions [hidden email]
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  -  [hidden email] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal