On 09 Jan 2016, at 05:15, Ben Coman <btc@openinworld.com> wrote:

On Sat, Jan 9, 2016 at 7:12 AM, Mariano Martinez Peck
<marianopeck@gmail.com> wrote:

On Jan 8, 2016 4:13 PM, "Ben Coman" <btc@openinworld.com> wrote:

On Sat, Jan 9, 2016 at 2:04 AM, Mariano Martinez Peck
<marianopeck@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

Your ExternalAddress use only allocates 4 bytes for the pointer.  You
need to also allocate the space for the structure.  I guess these may
need separate ExternalXXX objects, but just as hack experiment I find
below that n:=68 crashes and n:=69 its fine.

| posixSpawnFileActionsT n |
n := 68.  "n := 69"
posixSpawnFileActionsT := ExternalAddress allocate: n.
OSSUnixSubprocess new primitivePosixSpawnFileActionsInit:
posixSpawnFileActionsT.
posixSpawnFileActionsT free.


In trying to understand this I found an interesting article...
    http://www.catb.org/esr/structure-packing/
What I don't know is for a 32-bit OS on a 64-bit machine, is my
pointer 4 or 8 bytes?
Assuming 4 I derive the structure size for my 32-bit system is...
4      int __allocated;
4      int __used;
4      struct __spawn_action *__actions;
64    int __pad[16];
76    posix_spawn_file_actions_t;

76 - 68 = 8 is an interesting round number, but I can't quite reason it out.

With FFI how to you allocate some external memory and then get a
pointer to it to pass to primitivePosixSpawnFileActionsInit ?

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