Board index » delphi » Unexpected Crash in end of procedure

Unexpected Crash in end of procedure

Hi,

I'm working on a Pascal program (TP7.01) and I'm getting a weird problem :
There's an unexpected error that crashes my program in the end of a
procedure.
It seems like after the RET command, it jumps (wrongly, I think)
to CS:0000 .

Maybe the stack was altered wrongly in the procedure ?

Are there any special limits to the code size, data size, whatever,
that the compiler DOESN'T report on ?
I'm using the $M 30000 1024 150000 directive.
I'm also using some debug directives - Range, Overflow & Stack checkings
($R,Q,S) , however, no error is reported.

Any help is greatly appreciated,

Thanks,
        Idan.

 

Re:Unexpected Crash in end of procedure


On Sun, 12 Sep 1999 11:16:59 +0200, "Idan Nof" <idan...@hotmail.com>
wrote:

Quote
> I'm working on a Pascal program (TP7.01) and I'm getting a weird problem :
> There's an unexpected error that crashes my program in the end of a
> procedure.
> It seems like after the RET command, it jumps (wrongly, I think)
> to CS:0000 .

> Maybe the stack was altered wrongly in the procedure ?

Did YOU alter the stack ? If yes then have a second look at it - or
post it if it appears to be clean. Sometimes you don't see what there
is but what you want to see ;-)

To which RET do you refer ? Is it an "assembler" procedure where you
put you own RET or are you referring to what you saw in the de{*word*81}'s
output ?

Quote
> Are there any special limits to the code size, data size, whatever,
> that the compiler DOESN'T report on ?

I don't think so.

Regards
Horst

Re:Unexpected Crash in end of procedure


Someone wrote :

Quote
>> I'm working on a Pascal program (TP7.01) and I'm getting a weird problem
:
>> There's an unexpected error that crashes my program in the end of a
>> procedure.
>> It seems like after the RET command, it jumps (wrongly, I think)
>> to CS:0000 .

>> Maybe the stack was altered wrongly in the procedure ?

>Did YOU alter the stack ? If yes then have a second look at it - or
>post it if it appears to be clean. Sometimes you don't see what there
>is but what you want to see ;-)

Nope, I didn't mess up with the Stack, Pointers nor any ASM/INLINE
inst.

Btw, the 'bad' procedure is nested a few steps.

Quote

>To which RET do you refer ? Is it an "assembler" procedure where you
>put you own RET or are you referring to what you saw in the de{*word*81}'s
>output ?

I meant what I saw in the de{*word*81} ...

Re:Unexpected Crash in end of procedure


On Mon, 13 Sep 1999 17:39:26 +0200, "Idan Nof" <idan...@hotmail.com>
wrote:

Quote
> Someone wrote :
> >> I'm working on a Pascal program (TP7.01) and I'm getting a weird problem
> :
> >> There's an unexpected error that crashes my program in the end of a
> >> procedure.
> >> It seems like after the RET command, it jumps (wrongly, I think)
> >> to CS:0000 .

> >> Maybe the stack was altered wrongly in the procedure ?

> >Did YOU alter the stack ? If yes then have a second look at it - or
> >post it if it appears to be clean. Sometimes you don't see what there
> >is but what you want to see ;-)

> Nope, I didn't mess up with the Stack, Pointers nor any ASM/INLINE
> inst.

> Btw, the 'bad' procedure is nested a few steps.

I never heard of nor experienced problems with nested procedures in TP
due to a compiler error of some kind.

Is it true that in the whole execution path from the call to the
outmost procedure containing the nested procedures up to the call to
the 'bad' nested procedure you only used direct Pascal calls to the
procedures and you never use pointers  and {$S} is ON ?

Try to strip everything from the outmost procedure which will not make
disappear the error and post it.

Regards
Horst

Re:Unexpected Crash in end of procedure


Horst Kraemer wrote in <37dd3f0b.32210...@news.snafu.de>...

Quote

>Is it true that in the whole execution path from the call to the
>outmost procedure containing the nested procedures up to the call to
>the 'bad' nested procedure you only used direct Pascal calls to the
>procedures and you never use pointers  and {$S} is ON ?

>Try to strip everything from the outmost procedure which will not
make
>disappear the error and post it.

I remember now that some years ago I had a similar problem.  IIRC it
was one of my own library routines.  And Pascal might have been
version TP5.5 or maybe BP7.0.

The routine was very short and simple.  It produced some kind of stack
error.  When I disassembled and investigated it, I discovered that it
corrupted the stack.  I don't remember if it was an incorrect push or
pull and if it was too much or too less.  Anyway the compiler really
compiled erroneous code.

I managed to fix it by making a slight and non-relevant change to the
routine.  Then the compiler compiled it correctly.

So, Idan Nof, read your routine in assembler mode and follow
accurately what happens to the stack.

--

Raimo Suonio
raimo.suo...@qdlc.fi (remove spam preventing q)

Re:Unexpected Crash in end of procedure


Quote
>I managed to fix it by making a slight and non-relevant change to the
>routine.  Then the compiler compiled it correctly.

Hey, my lovely procedure behaves the same.
Whenever I delete a specific, non-relevant statement it is OK.

Quote
>So, Idan Nof, read your routine in assembler mode and follow
>accurately what happens to the stack.

I'm not sure I'll spend my next hours searching for a lovely PUSH or POP
that will give me nothing special when I find it, only a bigger headache.

I'll try to accept the un-prooved fact that it's THEIR bug,
and not mine.

Thanks,
          Idan.

Re:Unexpected Crash in end of procedure


On Wed, 15 Sep 1999 21:45:15 +0200, "Idan Nof" <idan...@hotmail.com>
wrote:

Quote
> I'll try to accept the un-prooved fact that it's THEIR bug,
> and not mine.

And I bet a hundred bucks that it is YOUR bug or a bug in some third
party units your program uses.

That fact that the behaviour disappears when you change an apparently
_irrelevant_ line of code litterally proves that it is not a code
generation bug.

Do you accept ?

Regards
Horst

Re:Unexpected Crash in end of procedure


Horst Kraemer wrote in <37e03b81.5034...@news.snafu.de>...

Quote

>And I bet a hundred bucks that it is YOUR bug or a bug in some third
>party units your program uses.

>That fact that the behaviour disappears when you change an apparently
>_irrelevant_ line of code litterally proves that it is not a code
>generation bug.

>Do you accept ?

In my case I could easily spot the error to a single line, and without
any doubt it was incorrectly compiled.

--

Raimo Suonio
raimo.suo...@qdlc.fi (remove spam preventing q)

Re:Unexpected Crash in end of procedure


Quote
"Raimo Suonio" <raimo.suo...@qdlc.fi> wrote:
>Horst Kraemer wrote in <37e03b81.5034...@news.snafu.de>...

>>And I bet a hundred bucks that it is YOUR bug or a bug in some third
>>party units your program uses.

>>That fact that the behaviour disappears when you change an apparently
>>_irrelevant_ line of code litterally proves that it is not a code
>>generation bug.

>>Do you accept ?

>In my case I could easily spot the error to a single line, and without
>any doubt it was incorrectly compiled.

So please post the relevant portion of your code, so we all can avoid
this "bug" in the future in our own programs.

Thank you. :->

Vinzent.

Re:Unexpected Crash in end of procedure


Vinzent Hoefler wrote in <7rrdg2$dk...@news07.btx.dtag.de>...

Quote

>So please post the relevant portion of your code, so we all can avoid
>this "bug" in the future in our own programs.

If I am some day able to reproduce the situation, I promise I will
tell you.

--

Raimo Suonio
raimo.suo...@qdlc.fi (remove spam preventing q)

Re:Unexpected Crash in end of procedure


Quote

>[Saved as file: C:\Programme\Agent\Problem.zip]

Hi,

If you know that your program is buggy you should enable all debug
compiler switches. Enabling Range check I found two errors:

1. Storing a negative number into a word (not critical)

2. Storing into an array with index out of range (very critical, may
be the filerec structure of output was demaged, resulting in 'File not
open...')

If you can live with my corrections here is a diff listing:

#################################################################
Verglichen werden SONGS.PAS und SONGS.NEW.
****** SONGS.PAS
   104:      CheckPause: Boolean;
   105:      Stri, TempStr: String;
****** SONGS.NEW
   104:      CheckPause: Boolean;
   105:      LongCount: longint;
   106:      Stri, TempStr: String;
******

****** SONGS.PAS
   346:           TempStr:=Copy(Line,1,Pos(' ',Line)-1);
   347:           Val(TempStr,Song.Pause[Count,W],Code);
   348:           Line:=strip(Line);
****** SONGS.NEW
   347:           TempStr:=Copy(Line,1,Pos(' ',Line)-1);
   348:           Val(TempStr,LongCount,Code);
   349:           if (Code=0) and (LongCount>=0) and
(LongCount<=$FFFF) then Song.Pause[Count,W] := LongCount;
   350:           Line:=strip(Line);
******

****** SONGS.PAS
   356:  {        If Line[1]='^' then Readln(InFile,Line)
   357:                         else }Song.Words[Count]:=LIne;
   358:          If (Song.Ready) and (Line<>'')
****** SONGS.NEW
   358:  {        If Line[1]='^' then Readln(InFile,Line)
   359:                         else }
   360:          if Count<=MaxLines then Song.Words[Count]:=LIne;
   361:          If (Song.Ready) and (Line<>'')
******
######################################################################

Hope that helps

Wolfgang
--
In order to e-mail me a reply to this message, you will have
to remove PLEASE.REMOVE from the address shown in the header.

Re:Unexpected Crash in end of procedure


JRS:  In article <7rtbe3$gj...@news2.inter.net.il> of Fri, 17 Sep 1999
14:16:34 in news:comp.lang.pascal.borland, Idan Nof

Quote
<idan...@hotmail.com> wrote:
>X-Complaints-To: ab...@inter.net.il
>Lines: 1342
>I do not guarantee it's THEIR problem so don't yell at me if I'm stupid !
>I hope it's OK to post a 57kb file.

>[ A UUEncoded file (Problem.zip) was included here. ]

It is not.

If you had read the weekly mini-FAQ, you would have known that.
If you had read the weekly meta-FAQ, you would have known that.
If you had read Timo's news-use FAQ, you would have known that.

Stupidity can be accepted at most once as a reason for not reporting you
for news abuse.

--
? John Stockton, Surrey, UK.   j...@merlyn.demon.co.uk    Turnpike v4.00   MIME.
  Web <URL:ftp://garbo.uwasa.fi/pc/link/tsfaqn.zip> -- Timo Salmi's Usenet Q&A.
  Web <URL:http://www.merlyn.demon.co.uk/news-use.htm>  -  about usage of News.
  No Encoding. Quote before replies. Snip well. Write clearly. Don't Mail News.

Re:Unexpected Crash in end of procedure


Quote
><idan...@hotmail.com> wrote:

>>X-Complaints-To: ab...@inter.net.il

>If you had read the weekly mini-FAQ, you would have known that.
>If you had read the weekly meta-FAQ, you would have known that.
>If you had read Timo's news-use FAQ, you would have known that.

Please accept my apologies, I haven't read the FAQ's and I wrongly
assumed that it was OK to post a 58k binary file.
Next time I'll post a pointer to that file ...

Quote
>Stupidity can be accepted at most once as a reason for not reporting you
>for news abuse.

OK.

Sorry,
      Idan.

Re:Unexpected Crash in end of procedure


Quote
> If you know that your program is buggy you should enable all debug
> compiler switches. Enabling Range check I found two errors:

You're absolutley right. I put {$R+} in the main program and
thought it affects the other units too.  seems like I was wrong.

Quote
> If you can live with my corrections here is a diff listing: ...

Thank you very much, once again you were right.
The program seems to work fine now.

Quote
> Hope that helps

Yes, thanks again.

Sincerely,
           Idan.

Re:Unexpected Crash in end of procedure


I've experienced a similar problem using TP 6.0 and found that the solution was
to move the CRT unit to the front of the UNIT declaration line.  It's been a
while, but as I recall, the order of declaration had to do with one of the
other unit trashing one of the CRT procedures during compilation, deleting a
return sequence, thereby causing execution to continue into the next procedure
in line, which trashes other code in the program.  This one caused me to lose
about 10% of what hair I had left, after about three days of debugging the
#$^%&$#  problem.
Go to page: [1] [2]

Other Threads