bugGforth - Bugs: bug #57741, Strange begin drop again ;

 
 

bug #57741: Strange begin drop again ;

Submitter:  Julián Albo <notfound>
Submitted:  Tue 04 Feb 2020 04:25:17 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  anton
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 05 Feb 2020 06:56:14 AM UTC, comment #5: 

fixed in the git head

Anton Ertl <anton>
Group administrator
Tue 04 Feb 2020 06:55:02 PM UTC, comment #4: 


comment #3:

> Ok, I'll fix it.  2DROP, FDROP and RDROP are also relevant, anything else?


2RDROP. All LP+ variants.

Bernd Paysan <paysan>
Group administrator
Tue 04 Feb 2020 06:49:30 PM UTC, comment #3: 

Ok, I'll fix it.  2DROP, FDROP and RDROP are also relevant, anything else?

Anton Ertl <anton>
Group administrator
Tue 04 Feb 2020 06:42:24 PM UTC, comment #2: 


comment #1:

> We could fix this by adding a memory access in DROP (and some other words), but I am not sure if this is worth the effort and the slowdown.


With the debugging engine (gforth), it's probably worth it.  We don't do TOS caching there only to get precise stack empty traps, and it hurts performance more than an unused read in DROP.

Bernd Paysan <paysan>
Group administrator
Tue 04 Feb 2020 04:38:13 PM UTC, comment #1: 

The gforth engine (without stack caching; for gforth-fast NIP would have the same effect as DROP for gforth) does not try to access the stack when DROPping.  In the usual case the stack underflow is discovered in the first word afterwards that accesses memory (e.g., because it actually does something with the stack item, or because it tries to push something), which is usually pretty soon.  Your example is one of the rare cases where this does not happen.  We could fix this by adding a memory access in DROP (and some other words), but I am not sure if this is worth the effort and the slowdown.

Anton Ertl <anton>
Group administrator
Tue 04 Feb 2020 04:25:17 PM UTC, original submission:  

I was trying to generate a stack underflow exception for some testing of CATCH, and found this:

: a begin drop again ;
' a catch .

Does not return to interactive mode, looks like it's trapped in an infinite loop.

But this

: a begin 1 drop drop again ;
' a catch .

Prints -4 as expected.

Using gforth 0.7.3 from the Debian 10 ia64 package.

Julián Albo <notfound>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by paysan (Posted a comment)
  • -email is unavailable- added by anton (Posted a comment)
  • -email is unavailable- added by notfound (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-02-05 anton StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2020-02-04 anton StatusNone Confirmed
        Assigned toNone anton

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code