On 16 November 2012 10:11, Max Leske <[email protected]> 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.
