--- Begin Message ---
> 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
> > <[email protected]> wrote:
> >
> > <mime-attachment>
--- End Message ---
