Ok... so I think that mapping the structures from FFI as defined in glibc would make it work in most if not all Linux right?
On Fri, Jan 8, 2016 at 10:17 PM, Mariano Martinez Peck < marianop...@gmail.com> wrote: > > > On Fri, Jan 8, 2016 at 8:41 PM, Nicolai Hess <nicolaih...@gmail.com> > wrote: > >> >> >> 2016-01-09 0:12 GMT+01:00 Mariano Martinez Peck <marianop...@gmail.com>: >> >>> >>> On Jan 8, 2016 4:13 PM, "Ben Coman" <b...@openinworld.com> wrote: >>> > >>> > On Sat, Jan 9, 2016 at 2:04 AM, Mariano Martinez Peck >>> > <marianop...@gmail.com> 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* >> >> >> > Yeah, damn. And the following text may explain why it DOES work on OSX: > > As an implementation detail, the externally visibily type > * posix_spawn_file_actions_t is defined to be a void *, and > * initialization involves allocation of a memory object. > * Subsequent changes to the spawn file actions may result in > * reallocation under the covers. > > > Extracted from > http://www.opensource.apple.com/source/Libc/Libc-583/sys/posix_spawn.c > > > > > 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 >>> > >>> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com
