Try loading NativeBoost-Mac-IgorStasenko.7 (and do NBMacConstants initialize, and then restart the image) see if it will fix the issue. On 18 November 2012 12:35, Igor Stasenko <siguctua@gmail.com> wrote:
On 16 November 2012 10:11, Max Leske <maxleske@gmail.com> wrote:
A followup on the munmap issue:
I think it has something to do with how NativeBoost does the lookup. I looked at the way that "mmap" is called and noticed that the selector #getGlobalSymbolPointer: is being used. Resolving "munmap" with this selector succeeds while doing
NativeBoost loadSymbol: 'munmap' aName fromModule: -2
(which is what happens when the heap manager tries to call "munmap") results the stack trace shown below.
I'll keep digging...
-2 corresponds to RTLD_DEFAULT on macs.. which i find a bit strange, because on linuxes it is 0. nevertheless, i discovered it when making mac-os port for NB.
I doubt, but who knows, maybe it is redefined to 0 in 10.8.x i am using 10.7 version so i cannot tell.
btw, can you tell us, what exactly error is signaled? inspect the exception object, or just evaluate 'self description' for exception..
Okay, it looks like i know what happens.. if you do
NativeBoost loadSymbol: 'munmap' fromModule: 0 or NativeBoost loadSymbol: 'munmap' fromModule: 16rFFFFFFFE it prints @ 16r9ACD2A26 but if you do
NativeBoost loadSymbol: 'munmap' fromModule: -2
it fails the call.. and i know why, because function signature in #bootstrapLoadSymbol:ofLength:fromModule:into: expects 'ulong moduleHandle' which is unsigned 32 bit int, while we passing something not really unsigned.. because it makes a call to #positive32BitValueOf: interpreter function which fails the primitive.
so, a fix would be to change -2 to 16rFFFFFFFE.
It appears that after putting order in type conversions, i made it more strict, and now passing negative values, where only positive expected is punished violently :)
It is in NBMacConstants method.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.