50g User RPL crasher (don't do this!)

[ettlz]

I don't know if this is known, and I know it's a bit too late for a firmware update, but still. This is a an HP50-C rev. 2.15. If you do this, back up first -- this corrupts the memory on mine.

I was playing with 'naked' lambdas in User RPL.

Code:

{ -> a << a 2 + >> } OBJ-> DROP 'func' STO

Next try to edit func.

Code:

'func' [ENTER] [LEFT-SHIFT] [DOWN]

It'll open up, press [ENTER] again and an error will flash briefly. Next pop anything onto the stack -- a number will do.

Watch the screen fill with garbage until the 'Try to recover?' prompt appears. Oops!

[Paul Berger (Canada)]

(08-05-2017 02:29 PM)ettlz Wrote:  I don't know if this is known, and I know it's a bit too late for a firmware update, but still. This is a an HP50-C rev. 2.15. If you do this, back up first -- this corrupts the memory on mine.

I was playing with 'naked' lambdas in User RPL.

Code:

{ -> a << a 2 + >> } OBJ-> DROP 'func' STO

Next try to edit func.

Code:

'func' [ENTER] [LEFT-SHIFT] [DOWN]

It'll open up, press [ENTER] again and an error will flash briefly. Next pop anything onto the stack -- a number will do.

Watch the screen fill with garbage until the 'Try to recover?' prompt appears. Oops!

Well my 50G was empty anyway so I tried this it would seem that what causes it to blow up is the lack of a space after 'OBJ' with a space between 'OBJ' and right arrow it is fine.

Paul.

[ettlz]

(08-05-2017 04:38 PM)Paul Berger (Canada) Wrote:  Well my 50G was empty anyway so I tried this it would seem that what causes it to blow up is the lack of a space after 'OBJ' with a space between 'OBJ' and right arrow it is fine.

Paul.

There shouldn't be a space there. It's calling OBJ→, which pushes all the elements of the preceding list to the stack and then pushes the number of elements (so the converse of →LIST). It's one way to get a → « ... » without enclosing it in « ... ».

[DavidM]

This is an interesting bug.

You can see it in a number of different ways, but I believe the salient pieces to make this happen are the following:

- You must VISIT a saved global with an otherwise empty stack (with VISIT, VISITB, or LS-DOWNARROW). All of these commands call the same internal routine (CharEdit). The empty stack issue is explained below.

- A simple form of the "offending" object is:

Code:

→ X « »

You can type that in while editing any object; it doesn't have to already exist in the saved function. Anything after the above code won't matter, but anything prior to it will possibly make a difference.

- You have to press "ENTER" while editing the object, which would normally result in the newly-edited object being saved into the global variable.

The problem seems to be related to the "→" actually getting executed (though it's not clear to me why that actually happens). It causes a loss of at least one item from the stack at a time when CharEdit isn't expecting that to occur. This ends up resulting in 1 or more items being missing from the stack that were supposed to be present, which in turn results in an attempt to drop stack items that aren't actually there. While the UserRPL DROP commands check the stack depth before proceeding, the SysRPL DROP commands do not. The crash happens because code was executed to drop items beyond the quantity that actually existed, which becomes evident as soon as you do anything to change the stack after executing the above steps.

You can see this in action by loading several items on the stack before attempting the "offending" steps, or alternatively by placing items on the stack in the edited object prior to the "→" command. Looking at the stored results in the global variable in those scenarios gives a clue to the "misalignment" of stack objects that happens.

Bottom line: don't do it. I can't imagine that we will ever see another firmware update to the 50g at this point.

Just curious: what is the goal of your experiments with a "naked lambda"? What are you trying to accomplish with this?

[ettlz]

Yes, it seems this can be triggered by creating something legit like « → X « » », storing it in a global, editing that global, and stripping the outer « ». This seems not an unreasonable mistake for a user to make. Ouch! Might a runtime patch be feasible? (This doesn't break the HP-48; if the stack is empty it (rightly) complains after you try and save the edit because it tries to evaluate the lambda.)

(08-05-2017 06:07 PM)DavidM Wrote:  Just curious: what is the goal of your experiments with a "naked lambda"? What are you trying to accomplish with this?

Just messing around in the unexplored corners of RPL... I like the flexible, functional design of the language -- which is part of what puts these calculators in another league.