2016-01-09 0:12 GMT+01:00 Mariano Martinez Peck <[email protected]>:
> > On Jan 8, 2016 4:13 PM, "Ben Coman" <[email protected]> wrote: > > > > On Sat, Jan 9, 2016 at 2:04 AM, Mariano Martinez Peck > > <[email protected]> wrote: > > > Hi guys, > > > > > > I wonder if someone could give me a hand to find out why a FFI calling > I am > > > doing is crashing. In OSX it works correct but I am testing in CentOS > and it > > > fails. I wonder if it also crashes in other Linuxes too. > > > > I only had enough time to run it a few time so you know it also > > crashes in Debian Jessie 32-bit. There were no debug logs. I got > > these sorts of messages... > > > > Thanks! > > > *** Error in `/home/ben/tst/pharo-vm/pharo': free(): invalid next size > > (fast): 0x08841a70 *** > > > > pharo: malloc.c:3695: _int_malloc: Assertion `(unsigned long) (size) > > >= (unsigned long) (nb)' failed. > > *** Error in `/home/ben/tst/pharo-vm/pharo': malloc(): memory > > corruption: 0x0984c1e0 *** > > > > > > Searching github for "posix_spawn_file_actions_init " ( > https://git.io/vuSPL) > > I see a lot a function definitions of the form... > > int posix_spawn_file_actions_init(posix_spawn_file_actions_t *fa) > > { > > fa->__actions = 0; > > return 0; > > } > > > > ...so it seems you need to first allocate the space for the struct and > > then pass the address of that. > > I thought the same. But I also read in glibc that that the init and > destroy would free and alloc exactly so that you don't have to do it. > > In fact, the structure is known to be opaque. I cannot rely in what I see > in internet since each os may have a different. > > And I cant get the size of it from ffi so I cannot allocate accurately. I > think I am screw. I don't want to go to plugin side grrr .. > > And osx does work. > > I think I will try against glibc rather than libc. > > Another idea? > > > { > > int __allocated; > > int __used; > > struct __spawn_action *__actions; > > int __pad[16]; > > } posix_spawn_file_actions_t; > > // http://linux.die.net/include/spawn.h > > > > But that's opaque right? I cannot rely on that > no, posix_spawn_file_actions_init is not supposed allocate the structure. http://linux.die.net/man/3/posix_spawn_file_actions_init: "The *posix_spawn_file_actions_init*() function shall *initialize the object referenced* > cheers -ben > > > > > > > > > > I am using latest Pharo 5.0 with Spur. To reproduce: > > > > > > 1) Get latest Pharo 5.0 and Spur via: > > > wget -O- get.pharo.org/alpha+vm | bash > > > > > > 2) Inside Pharo, load my prototype tool: > > > > > > Gofer it > > > package: 'OSSubprocess'; > > > url: 'http://smalltalkhub.com/mc/marianopeck/OSSubprocess/main'; > > > load. > > > > > > 3) This is the code I am executing and it's crashing: > > > > > > | posixSpawnFileActionsT | posixSpawnFileActionsT := ExternalAddress > > > allocate: 4. OSSUnixSubprocess new primitivePosixSpawnFileActionsInit: > > > posixSpawnFileActionsT. posixSpawnFileActionsT free. > > > 4) The primitive is as simple as: > > > > > > primitivePosixSpawnFileActionsInit: aPosixSpawnFileActionsT > > > ^ self ffiCall: #( int posix_spawn_file_actions_init(void* > > > aPosixSpawnFileActionsT) ) module: LibC > > > > > > I have no idea what I am doing wrong. And again, this works on OSX. The > > > function I am calling is: int > > > posix_spawn_file_actions_init(posix_spawn_file_actions_t > *file_actions); as > > > you can read in [1] > > > > > > Below is the stacktrace I get the Linux terminal. > > > > > > Any hint is greatly appreciated. > > > > > > Thanks, > > > > > > > > > [1] > > > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn_file_actions_destroy.html > > >
