Programmatically changing Entry mode crashes iOS Pro App

[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