Programmatically changing Entry mode crashes iOS Pro App

[pinkman]

Hi,
I created the following function to automatically switch between Textbook and RPN modes:

Code:


KEY K_Menu()
BEGIN
 LOCAL s := {"Textbook", "Algebraic", "RPN"};
 Entry := ABS(Entry-2);
 TEXTOUT_P(s(Entry+1), 15, 9, 1, RGB(255,180,80));
 WAIT(1);
 RETURN -1; // see edit comment below
END;

It works fine on my physical HP Prime, but on the iOS App it crashes every 2 switches.
Am I doing something wrong?

Thanks,
Thibault

PS: yes I know, in case of algebraic mode it stays in this mode, but I never use it.

[edit] Added « RETURN -1; » in the code, according to Cyrille’s suggestion (just in case you copy it directly to your Prime without reading the whole thread)

[pinkman]

Well I finally succeeded in crashing the HW Prime with this code assigned to a user key.
Does someone see what I’m doing wrong?

Thanks

[rprosperi]

I've no idea at all what the problem is, but I recalled that this is one of the first programs I found useful on the Prime, back in 2014:

https://www.hpmuseum.org/forum/thread-801.html

Although slightly different, the program there may offer insights as to why this isn't working.

[cyrille de brébisson]

Hello,

Well, it took me a couple of hours to chase that one up, but I found the problem!

The geist of it is that, when you do a mode change, the graphical control gets changed from (for example) the RPN stack to the algebraic stack.
So, the system deletes the RPN stack and creates an algebraic stack...
Up to here, no problem...

HOWEVER,
your user key program returns 1. Which, had you read the documentation (I know that I documented it somewhere, but do not ask me where!!!!) means that the system is expected to execute key "1" (symb)....

The problem is that it would send the execution of said key 1 to the now defunct/deleted stack. -> crash!

So, I have added some code to avoid the crash in the future... BUT you can also fix things on your side by adding a return -1 at the end of your program.

Hope this helps...
Cyrille

[pinkman]

(05-27-2020 07:11 AM)cyrille de brébisson Wrote:  Hello,

Well, it took me a couple of hours to chase that one up, but I found the problem!

The geist of it is that, when you do a mode change, the graphical control gets changed from (for example) the RPN stack to the algebraic stack.
So, the system deletes the RPN stack and creates an algebraic stack...
Up to here, no problem...

HOWEVER,
your user key program returns 1. Which, had you read the documentation (I know that I documented it somewhere, but do not ask me where!!!!) means that the system is expected to execute key "1" (symb)....

The problem is that it would send the execution of said key 1 to the now defunct/deleted stack. -> crash!

So, I have added some code to avoid the crash in the future... BUT you can also fix things on your side by adding a return -1 at the end of your program.

Hope this helps...
Cyrille

Thank you Cyrille, lots of helpful answers.
I turned around the RETURN -1 without finding it in the documentation, and indeed my code generates erratic behavior because of random return values.
I also understood that there was a loss of coherence when changing the view, but there again, without finding the solution. In event oriented programming I should have sent a “redraw” message to the window manager.

[cyrille de brébisson]

Hello,

User keys can return 3 things:
1) a string. In this case, this string will be treated as a "textEvent", which, in most cases means that it gets sent to the command line.
2) a number between 0 and 51*4(?). This number is treated as a keycode which gets executed if possible.
3) -1. In this case nothing else happends...

Now, the problem is that, in the case of string or number, the message gets sent to the window/control that received the original message.
BUT, if your code causes a view change (setview or, in your case a switch of entry mode), said window/control is destroyed before the 2nd action is executed. So the message goes nowhere... Causing the issue.

Cyrille

[pinkman]

Thanks Cyrille.
Yes I had this in mind. I did not know the RETURN -1 option, my code tried to return nothing, but this does not really exist in HPPL.

The issue is clear for me:
- changing view drives to lose what I would call the calling context: it is not a bug,
- not handling such cases when returning from a program: this is the bug.

Now I’m wondering why the crash occurred randomly...

[cyrille de brébisson]

Hello,

Yes, in PPL, there is no "no return" function. They all return the latest expression's result. If the function is empty, it returns a 0.

>not handling such cases when returning from a program: this is the bug
Yep, and I am fixing it... But you can "avoid" the bug by returning a -1, which would solve the problem in the meantime.

>Now I’m wondering why the crash occurred randomly...
Here was the code (I have changed it since):
Here we are in a member function of the Window object.
if(!DoUserKeys(m, handled)) return true; // If the key is a user function and fully handled, return. If NOT fully handled, it will have modified the message (m)
return KeyEvent(&m->KeyEvent); // This is a virtual function call to KeyEvent

In our case, DoUserKeys would do a view change, which was deleting 'this', ie: the current window, ie: the object which member function we are executing.
now, of course a memeory free does not mean that the data in the memory is wipped out, just "released"... the memory location can be overridend imediately, or much later...
The call to KeyEvent, in most case would execute nothing. But would still do a virtual function call, which meant that it would read the memory at the start of the window class instance to get the class pointer, and then read the address of the, potentially, overriden KeyEvent virtual function to "jump" there.
Now, if the begining of the now deleted window object memory are was NOT overiden (which seemed to happen most times), then the call would succeed, and do nothing, which is not a big issue...
BUT, if that memory area was overriden between the time of deletion and the time when the call to KeyEvent was executed, then the CPU would jump God knows where, and it would crash.

As you can imagine, things are kind of random ad the call to DoUserKeys is quite complex, executing a PPL user program, doing a view switch and everything! Hence the randomness!

Hope that helps!
Cyrille

[pinkman]

It helps, thanks for the details.
I guess that, running at iPhone X speed, chances that the memory will be overridden are greater on the iOS app than on my (good old) G1.

You said you correct it, could tell us how? I’m just curious...

[cyrille de brébisson]

Hello,

>You said you correct it, could tell us how? I’m just curious...
Well, it is a bug, once you have found what is causing the bug, corrections are usually not that hard.
I have added a way to mark/record graphical controls deletions within a sub function.
I use this to test if the graphical control is deleted in the sub function and act accordingly if it happens.

It should be "live" in a next release (no dates provided)...

Cyrille

[pinkman]

(06-01-2020 06:40 AM)cyrille de brébisson Wrote:  Hello,
>You said you correct it, could tell us how? I’m just curious...
Well, it is a bug, once you have found what is causing the bug, corrections are usually not that hard.

Unless the correction calls into question the structure of the code.

Quote:It should be "live" in a next release (no dates provided)...

Thanks. I’m volunteering to debug the next beta if needed.

Regards,
Thibault

[CyberAngel]

(05-29-2020 05:12 AM)cyrille de brébisson Wrote:  Hello,

Yes, in PPL, there is no "no return" function. They all return the latest expression's result. If the function is empty, it returns a 0.

>not handling such cases when returning from a program: this is the bug
Yep, and I am fixing it... But you can "avoid" the bug by returning a -1, which would solve the problem in the meantime.

>Now I’m wondering why the crash occurred randomly...
Here was the code (I have changed it since):
Here we are in a member function of the Window object.
if(!DoUserKeys(m, handled)) return true; // If the key is a user function and fully handled, return. If NOT fully handled, it will have modified the message (m)
return KeyEvent(&m->KeyEvent); // This is a virtual function call to KeyEvent

In our case, DoUserKeys would do a view change, which was deleting 'this', ie: the current window, ie: the object which member function we are executing.
now, of course a memeory free does not mean that the data in the memory is wipped out, just "released"... the memory location can be overridend imediately, or much later...
The call to KeyEvent, in most case would execute nothing. But would still do a virtual function call, which meant that it would read the memory at the start of the window class instance to get the class pointer, and then read the address of the, potentially, overriden KeyEvent virtual function to "jump" there.
Now, if the begining of the now deleted window object memory are was NOT overiden (which seemed to happen most times), then the call would succeed, and do nothing, which is not a big issue...
BUT, if that memory area was overriden between the time of deletion and the time when the call to KeyEvent was executed, then the CPU would jump God knows where, and it would crash.

As you can imagine, things are kind of random ad the call to DoUserKeys is quite complex, executing a PPL user program, doing a view switch and everything! Hence the randomness!

Hope that helps!
Cyrille

Cyrille,
are any of these different window objects fixed in size or do they grow RAM permitting?
Maybe they could have a FIXED address and also be PERMANENTLY reserved.
At least the G2 has enormous RAM and I guess the code base is separate from G1.
- -
VPN

[cyrille de brébisson]

Hello,

on prime, as on older versions of windows, a single framebuffer is mapped on a number of tree organized window objects which can be on top of each other, contain each others and can intersect.

the framebuffer is unique to save memory.

fixed addresses is not a good option here as lots of windows can be created (including user ones, when you do an input or a msgbox, you create a window object)...

Cyrille

[Carlos295pz]

This too:
4) -2 or less will perform default key behavior

(05-28-2020 05:59 AM)cyrille de brébisson Wrote:  User keys can return 3 things:
1) a string. In this case, this string will be treated as a "textEvent", which, in most cases means that it gets sent to the command line.
2) a number between 0 and 51*4(?). This number is treated as a keycode which gets executed if possible.
3) -1. In this case nothing else happends...