Hi Petr,

along with Esteban’s request for the error code from allocateExecutablePage can you also see whether use of iceberg is successful the second time you launch Pharo? So start up your virtualbox, try and interact with iceberg, quit if it fails, relaunch and try again?

Yes, after the tests were green (second time, after magic happens), Iceberg was also OK - and I mean the whole Iceberg cycle up to creating the Pharo pull request right from the Iceberg UI/image. I recreated whole virtualbox image from scratch and tune some vbox settings - described problems have gone and I am not able to recreate the same situation - let's forget it, it's not the Pharo thing. And finally - I see that a lot of work has been done on Iceberg - it's not even necessary to leave Pharo for a minute due to the final Github pull request in web browser, nice. pf

Also in your steps what do you do to prepare? eg do you boot in virtualbox, return from sleep, or...?

FYI, allocateExecutablePage uses valloc (IIRC) to get a page from the OS and then uses mprotect to add executable permission to the page before answering the page’s address as the result of the primitive. The callback machinery then uses the page to provide the executable blue code used in implementing callbacks. The address of a code sequence in the page is what is actually handed out to C code as a fu croon pointer. When external code calls this function pointer the code in the sequence invokes a callback into the vm before returning back to C. Consequently it is key that allocateExecutablePage works correctly. If it doesn’t then no callbacks.

_,,,^..^,,,_ (phone)

...

On Sep 24, 2018, at 11:11 AM, Petr Fischer via Pharo-dev <pharo-dev@lists.pharo.org> wrote:

<mime-attachment>