Help with FFI crash in latest Spur (only in Linux)
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 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_a... **** Error in `/home/centos/pharo-vm/pharo': malloc(): memory corruption (fast): 0x09544268 **** ======= Backtrace: ========= /lib/libc.so.6(+0x7428c)[0xf758e28c] /lib/libc.so.6(+0x76d98)[0xf7590d98] /lib/libc.so.6(__libc_calloc+0xa7)[0xf7592df7] /home/centos/pharo-vm/pharo[0x80b8f44] /home/centos/pharo-vm/pharo[0x80b909c] /home/centos/pharo-vm/pharo(ioLoadExternalFunctionOfLengthFromModuleOfLengthAccessorDepthInto+0xc2)[0x80b9402] /home/centos/pharo-vm/pharo[0x808de6f] /home/centos/pharo-vm/pharo[0x80a0810] /home/centos/pharo-vm/pharo(ceSendsupertonumArgs+0x1da)[0x80a1f4a] [0x960004c] [0x9600b00] [0xaec2e9b] [0xaec3481] [0x9604ff0] [0x964ed43] [0x9604f5c] [0x960424c] [0x9602e47] [0x9602be7] [0x960320c] [0x9602277] [0x960bec2] [0x9600b00] [0x9600ad8] ======= Memory map: ======== 08048000-08151000 r-xp 00000000 fd:01 202178584 /home/centos/pharo-vm/pharo 08151000-08152000 r--p 00108000 fd:01 202178584 /home/centos/pharo-vm/pharo 08152000-0815c000 rw-p 00109000 fd:01 202178584 /home/centos/pharo-vm/pharo 0815c000-08193000 rw-p 00000000 00:00 0 09505000-095a5000 rw-p 00000000 00:00 0 [heap] 09600000-09701000 rwxp 00000000 00:00 0 09701000-0dbc0000 rw-p 00000000 00:00 0 f6de5000-f6dfe000 r-xp 00000000 fd:01 203854803 /usr/lib/libgcc_s-4.8.5-20150702.so.1 f6dfe000-f6dff000 r--p 00018000 fd:01 203854803 /usr/lib/libgcc_s-4.8.5-20150702.so.1 f6dff000-f6e00000 rw-p 00019000 fd:01 203854803 /usr/lib/libgcc_s-4.8.5-20150702.so.1 f6e00000-f6e21000 rw-p 00000000 00:00 0 f6e21000-f6f00000 ---p 00000000 00:00 0 f6f25000-f6f26000 rw-p 00000000 00:00 0 f6f26000-f6f2e000 r-xp 00000000 fd:01 202178580 /home/centos/pharo-vm/libSqueakFFIPrims.so f6f2e000-f6f2f000 r--p 00007000 fd:01 202178580 /home/centos/pharo-vm/libSqueakFFIPrims.so f6f2f000-f6f30000 rw-p 00008000 fd:01 202178580 /home/centos/pharo-vm/libSqueakFFIPrims.so f6f30000-f6f32000 r-xp 00000000 fd:01 203140415 /usr/lib/libXau.so.6.0.0 f6f32000-f6f33000 r--p 00001000 fd:01 203140415 /usr/lib/libXau.so.6.0.0 f6f33000-f6f34000 rw-p 00002000 fd:01 203140415 /usr/lib/libXau.so.6.0.0 f6f34000-f6f5b000 r-xp 00000000 fd:01 201498737 /usr/lib/liblzma.so.5.0.99 f6f5b000-f6f5d000 r--p 00026000 fd:01 201498737 /usr/lib/liblzma.so.5.0.99 f6f5d000-f6f5e000 rw-p 00028000 fd:01 201498737 /usr/lib/liblzma.so.5.0.99 f6f5e000-f6fc0000 r-xp 00000000 fd:01 201348055 /usr/lib/libpcre.so.1.2.0 f6fc0000-f6fc2000 r--p 00061000 fd:01 201348055 /usr/lib/libpcre.so.1.2.0 f6fc2000-f6fc3000 rw-p 00063000 fd:01 201348055 /usr/lib/libpcre.so.1.2.0 f6fc3000-f6fcf000 r-xp 00000000 fd:01 202740809 /usr/lib/libdrm.so.2.4.0 f6fcf000-f6fd0000 r--p 0000b000 fd:01 202740809 /usr/lib/libdrm.so.2.4.0 f6fd0000-f6fd1000 rw-p 0000c000 fd:01 202740809 /usr/lib/libdrm.so.2.4.0 f6fd1000-f6fd5000 r-xp 00000000 fd:01 202740799 /usr/lib/libXxf86vm.so.1.0.0 f6fd5000-f6fd6000 r--p 00004000 fd:01 202740799 /usr/lib/libXxf86vm.so.1.0.0 f6fd6000-f6fd7000 rw-p 00005000 fd:01 202740799 /usr/lib/libXxf86vm.so.1.0.0 f6fd7000-f6fd8000 r-xp 00000000 fd:01 201522922 /usr/lib/libxshmfence.so.1.0.0 f6fd8000-f6fd9000 r--p 00000000 fd:01 201522922 /usr/lib/libxshmfence.so.1.0.0 f6fd9000-f6fda000 rw-p 00001000 fd:01 201522922 /usr/lib/libxshmfence.so.1.0.0 f6fda000-f6ffd000 r-xp 00000000 fd:01 202740769 /usr/lib/libxcb.so.1.1.0 f6ffd000-f6ffe000 r--p 00022000 fd:01 202740769 /usr/lib/libxcb.so.1.1.0 f6ffe000-f6fff000 rw-p 00023000 fd:01 202740769 /usr/lib/libxcb.so.1.1.0 f6fff000-f7004000 r-xp 00000000 fd:01 201522899 /usr/lib/libxcb-sync.so.1.0.0 f7004000-f7005000 r--p 00005000 fd:01 201522899 /usr/lib/libxcb-sync.so.1.0.0 f7005000-f7006000 rw-p 00006000 fd:01 201522899 /usr/lib/libxcb-sync.so.1.0.0 f7006000-f7009000 r-xp 00000000 fd:01 201522895 /usr/lib/libxcb-shape.so.0.0.0 f7009000-f700a000 r--p 00002000 fd:01 201522895 /usr/lib/libxcb-shape.so.0.0.0 f700a000-f700b000 rw-p 00003000 fd:01 201522895 /usr/lib/libxcb-shape.so.0.0.0 f700b000-f7014000 r-xp 00000000 fd:01 201522889 /usr/lib/libxcb-render.so.0.0.0 f7014000-f7015000 r--p 00008000 fd:01 201522889 /usr/lib/libxcb-render.so.0.0.0 f7015000-f7016000 rw-p 00009000 fd:01 201522889 /usr/lib/libxcb-render.so.0.0.0 f7016000-f701d000 r-xp 00000000 fd:01 201522905 /usr/lib/libxcb-xfixes.so.0.0.0 f701d000-f701e000 r--p 00006000 fd:01 201522905 /usr/lib/libxcb-xfixes.so.0.0.0 f701e000-f701f000 rw-p 00007000 fd:01 201522905 /usr/lib/libxcb-xfixes.so.0.0.0 f701f000-f702c000 r-xp 00000000 fd:01 201522885 /usr/lib/libxcb-randr.so.0.1.0 f702c000-f702d000 r--p 0000d000 fd:01 201522885 /usr/lib/libxcb-randr.so.0.1.0 f702d000-f702e000 rw-p 0000e000 fd:01 201522885 /usr/lib/libxcb-randr.so.0.1.0 f702e000-f7030000 r-xp 00000000 fd:01 201522883 /usr/lib/libxcb-present.so.0.0.0 f7030000-f7031000 r--p 00001000 fd:01 201522883 /usr/lib/libxcb-present.so.0.0.0 f7031000-f7032000 rw-p 00002000 fd:01 201522883 /usr/lib/libxcb-present.so.0.0.0 f7032000-f7034000 r-xp 00000000 fd:01 203140423 /usr/lib/libxcb-dri3.so.0.0.0 f7034000-f7035000 r--p 00001000 fd:01 203140423 /usr/lib/libxcb-dri3.so.0.0.0 f7035000-f7036000 rw-p 00002000 fd:01 203140423 /usr/lib/libxcb-dri3.so.0.0.0 f7036000-f703a000 r-xp 00000000 fd:01 203140421 /usr/lib/libxcb-dri2.so.0.0.0./pharo-ui: line 11: 4019 Aborted (core dumped) "$DIR"/"pharo-vm/pharo" "$@" -- Mariano http://marianopeck.wordpress.com
On Fri, Jan 8, 2016 at 3:04 PM, 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 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.
If I change above line with this: posixSpawnFileActionsT := ByteArray new: 4. Then the function does not crash but it crashes in the future posix_spawn_file_actions_destroy(). -- Mariano http://marianopeck.wordpress.com
On 08 Jan 2016, at 19:35, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Fri, Jan 8, 2016 at 3:04 PM, Mariano Martinez Peck <marianopeck@gmail.com <mailto: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 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 <http://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 <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.
If I change above line with this:
posixSpawnFileActionsT := ByteArray new: 4.
Wil this not allocate more the four bytes because of the object header? So how about allocating 8 bytes for the pointer (just for fun)? ExternalAddress allocate: 8
Then the function does not crash but it crashes in the future posix_spawn_file_actions_destroy().
-- Mariano http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>
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... *** 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. { int __allocated; int __used; struct __spawn_action *__actions; int __pad[16]; } posix_spawn_file_actions_t; // http://linux.die.net/include/spawn.h 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_a...
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
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_a...
2016-01-09 0:12 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com>:
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
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_a...
On Fri, Jan 8, 2016 at 8:41 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-01-09 0:12 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com>:
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
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_a...
-- Mariano http://marianopeck.wordpress.com
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 < marianopeck@gmail.com> wrote:
On Fri, Jan 8, 2016 at 8:41 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-01-09 0:12 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com>:
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
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_a...
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
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_a...
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 <mailto: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.
if it is opaque, they do not provide a function to create one?
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 ..
but you can map it and you will get the size. or you can hardcode it (not so bad, if done in the appropriate place), if is opaque, you do not need to map the structure, just know the size and allocate that. Esteban
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/ <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_a...
On Sat, Jan 9, 2016 at 12:15 PM, 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.
Whoops, I missed that the space for the struct seems actually allocated by ExternalAddress. Doh! there it is staring at me with the #allocate: message. So I guess a separate ExternalXXX object isn't required.
| 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.
btw I confirmed *my* structure size by compiling and running... #include <stdio.h> #include <spawn.h> posix_spawn_file_actions_t tst; int main() { printf("-->sizeof=%d\n", sizeof(posix_spawn_file_actions_t)); } -->sizeof=76 cheers -ben
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_a...
Hi Ben, allf Ok, I can also confirm that doing ExternalAddress allocate: 76 does work in Linux. And yes, since it's opaque I don't have to map it and just allocating the correct size is enough. I expect this would work in all GNU libc (glibc) based UNIXses. Esteban, well, I thought the init function would do both, allocate and init, but in glibc it seems it only init. In OSX it seems it does both. But from the API point of view it's not explicit that they should allocate the space. Anyway, I think we get this working this time. Thanks all for the help. Now the problem I am facing (in Linux) is that my none blocking pipes do not seem to be none blocking or either feof() call is not working as expected. Ok, I have to deal with this one now. Thanks!! On Sat, Jan 9, 2016 at 9:44 AM, Ben Coman <btc@openinworld.com> wrote:
On Sat, Jan 9, 2016 at 12:15 PM, 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.
Whoops, I missed that the space for the struct seems actually allocated by ExternalAddress. Doh! there it is staring at me with the #allocate: message. So I guess a separate ExternalXXX object isn't required.
| 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.
btw I confirmed *my* structure size by compiling and running... #include <stdio.h> #include <spawn.h> posix_spawn_file_actions_t tst; int main() { printf("-->sizeof=%d\n", sizeof(posix_spawn_file_actions_t)); }
-->sizeof=76
cheers -ben
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_a...
-- Mariano http://marianopeck.wordpress.com
On Sat, Jan 9, 2016 at 8:54 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi Ben, allf
Ok, I can also confirm that doing ExternalAddress allocate: 76 does work in Linux. And yes, since it's opaque I don't have to map it and just allocating the correct size is enough.
Its probably not 76 bytes in 64-bit though. Can someone on 64-bit report the result of my little C-code sample. Probably its okay initially to waste a few bytes on 32-bit until we have something to calculate these at runtime (btw, what is the current state/plans for such a feature).
I expect this would work in all GNU libc (glibc) based UNIXses. Esteban, well, I thought the init function would do both, allocate and init, but in glibc it seems it only init. In OSX it seems it does both. But from the API point of view it's not explicit that they should allocate the space.
Anyway, I think we get this working this time. Thanks all for the help.
Now the problem I am facing (in Linux) is that my none blocking pipes do not seem to be none blocking or either feof() call is not working as expected. Ok, I have to deal with this one now.
Do you have any code samples? Sounds like an interesting thing to have a look at. cheers -ben
Thanks!!
On Sat, Jan 9, 2016 at 9:44 AM, Ben Coman <btc@openinworld.com> wrote:
On Sat, Jan 9, 2016 at 12:15 PM, 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.
Whoops, I missed that the space for the struct seems actually allocated by ExternalAddress. Doh! there it is staring at me with the #allocate: message. So I guess a separate ExternalXXX object isn't required.
| 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.
btw I confirmed *my* structure size by compiling and running... #include <stdio.h> #include <spawn.h> posix_spawn_file_actions_t tst; int main() { printf("-->sizeof=%d\n", sizeof(posix_spawn_file_actions_t)); }
-->sizeof=76
cheers -ben
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_a...
-- Mariano http://marianopeck.wordpress.com
Mariano, if you followed the approach I described recently you wouldn't be having these problems. Instead, the system would be generating the information you need to know about sizes for you automatically. Eventually you're going to have to grasp the nettle of how to import platform-specific information such as structure sizes, values of $defines, layout of structs, etc, etc. I presented a straightforward approach but you've yet to comment on it. On Sat, Jan 9, 2016 at 4:54 AM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
Hi Ben, allf
Ok, I can also confirm that doing ExternalAddress allocate: 76 does work in Linux. And yes, since it's opaque I don't have to map it and just allocating the correct size is enough. I expect this would work in all GNU libc (glibc) based UNIXses. Esteban, well, I thought the init function would do both, allocate and init, but in glibc it seems it only init. In OSX it seems it does both. But from the API point of view it's not explicit that they should allocate the space.
Anyway, I think we get this working this time. Thanks all for the help.
Now the problem I am facing (in Linux) is that my none blocking pipes do not seem to be none blocking or either feof() call is not working as expected. Ok, I have to deal with this one now.
Thanks!!
On Sat, Jan 9, 2016 at 9:44 AM, Ben Coman <btc@openinworld.com> wrote:
On Sat, Jan 9, 2016 at 12:15 PM, 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.
Whoops, I missed that the space for the struct seems actually allocated by ExternalAddress. Doh! there it is staring at me with the #allocate: message. So I guess a separate ExternalXXX object isn't required.
| 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.
btw I confirmed *my* structure size by compiling and running... #include <stdio.h> #include <spawn.h> posix_spawn_file_actions_t tst; int main() { printf("-->sizeof=%d\n", sizeof(posix_spawn_file_actions_t)); }
-->sizeof=76
cheers -ben
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_a...
-- Mariano http://marianopeck.wordpress.com
-- _,,,^..^,,,_ best, Eliot
On Sat, Jan 9, 2016 at 4:15 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Mariano,
if you followed the approach I described recently you wouldn't be having these problems. Instead, the system would be generating the information you need to know about sizes for you automatically. Eventually you're going to have to grasp the nettle of how to import platform-specific information such as structure sizes, values of $defines, layout of structs, etc, etc. I presented a straightforward approach but you've yet to comment on it.
Hi Eliot, I read all that thread carefully and indeed, I would like to comment on it. Please, give me some time and I will share my thoughts. Thanks!
On Sat, Jan 9, 2016 at 4:54 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi Ben, allf
Ok, I can also confirm that doing ExternalAddress allocate: 76 does work in Linux. And yes, since it's opaque I don't have to map it and just allocating the correct size is enough. I expect this would work in all GNU libc (glibc) based UNIXses. Esteban, well, I thought the init function would do both, allocate and init, but in glibc it seems it only init. In OSX it seems it does both. But from the API point of view it's not explicit that they should allocate the space.
Anyway, I think we get this working this time. Thanks all for the help.
Now the problem I am facing (in Linux) is that my none blocking pipes do not seem to be none blocking or either feof() call is not working as expected. Ok, I have to deal with this one now.
Thanks!!
On Sat, Jan 9, 2016 at 9:44 AM, Ben Coman <btc@openinworld.com> wrote:
On Sat, Jan 9, 2016 at 12:15 PM, 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.
Whoops, I missed that the space for the struct seems actually allocated by ExternalAddress. Doh! there it is staring at me with the #allocate: message. So I guess a separate ExternalXXX object isn't required.
| 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.
btw I confirmed *my* structure size by compiling and running... #include <stdio.h> #include <spawn.h> posix_spawn_file_actions_t tst; int main() { printf("-->sizeof=%d\n", sizeof(posix_spawn_file_actions_t)); }
-->sizeof=76
cheers -ben
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_a...
-- Mariano http://marianopeck.wordpress.com
-- _,,,^..^,,,_ best, Eliot
-- Mariano http://marianopeck.wordpress.com
Le 08/01/2016 19:04, Mariano Martinez Peck a écrit :
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 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 <http://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_a...
* * **** Error in `/home/centos/pharo-vm/pharo': malloc(): memory corruption (fast): 0x09544268 **** ======= Backtrace: ========= /lib/libc.so.6(+0x7428c)[0xf758e28c] /lib/libc.so.6(+0x76d98)[0xf7590d98] /lib/libc.so.6(__libc_calloc+0xa7)[0xf7592df7] /home/centos/pharo-vm/pharo[0x80b8f44] /home/centos/pharo-vm/pharo[0x80b909c] /home/centos/pharo-vm/pharo(ioLoadExternalFunctionOfLengthFromModuleOfLengthAccessorDepthInto+0xc2)[0x80b9402] /home/centos/pharo-vm/pharo[0x808de6f] /home/centos/pharo-vm/pharo[0x80a0810] /home/centos/pharo-vm/pharo(ceSendsupertonumArgs+0x1da)[0x80a1f4a] [0x960004c] [0x9600b00] [0xaec2e9b] [0xaec3481] [0x9604ff0] [0x964ed43] [0x9604f5c] [0x960424c] [0x9602e47] [0x9602be7] [0x960320c] [0x9602277] [0x960bec2] [0x9600b00] [0x9600ad8] ======= Memory map: ======== 08048000-08151000 r-xp 00000000 fd:01 202178584 /home/centos/pharo-vm/pharo 08151000-08152000 r--p 00108000 fd:01 202178584 /home/centos/pharo-vm/pharo 08152000-0815c000 rw-p 00109000 fd:01 202178584 /home/centos/pharo-vm/pharo 0815c000-08193000 rw-p 00000000 00:00 0 09505000-095a5000 rw-p 00000000 00:00 0 [heap] 09600000-09701000 rwxp 00000000 00:00 0 09701000-0dbc0000 rw-p 00000000 00:00 0 f6de5000-f6dfe000 r-xp 00000000 fd:01 203854803 /usr/lib/libgcc_s-4.8.5-20150702.so.1 f6dfe000-f6dff000 r--p 00018000 fd:01 203854803 /usr/lib/libgcc_s-4.8.5-20150702.so.1 f6dff000-f6e00000 rw-p 00019000 fd:01 203854803 /usr/lib/libgcc_s-4.8.5-20150702.so.1 f6e00000-f6e21000 rw-p 00000000 00:00 0 f6e21000-f6f00000 ---p 00000000 00:00 0 f6f25000-f6f26000 rw-p 00000000 00:00 0 f6f26000-f6f2e000 r-xp 00000000 fd:01 202178580 /home/centos/pharo-vm/libSqueakFFIPrims.so f6f2e000-f6f2f000 r--p 00007000 fd:01 202178580 /home/centos/pharo-vm/libSqueakFFIPrims.so f6f2f000-f6f30000 rw-p 00008000 fd:01 202178580 /home/centos/pharo-vm/libSqueakFFIPrims.so f6f30000-f6f32000 r-xp 00000000 fd:01 203140415 /usr/lib/libXau.so.6.0.0 f6f32000-f6f33000 r--p 00001000 fd:01 203140415 /usr/lib/libXau.so.6.0.0 f6f33000-f6f34000 rw-p 00002000 fd:01 203140415 /usr/lib/libXau.so.6.0.0 f6f34000-f6f5b000 r-xp 00000000 fd:01 201498737 /usr/lib/liblzma.so.5.0.99 f6f5b000-f6f5d000 r--p 00026000 fd:01 201498737 /usr/lib/liblzma.so.5.0.99 f6f5d000-f6f5e000 rw-p 00028000 fd:01 201498737 /usr/lib/liblzma.so.5.0.99 f6f5e000-f6fc0000 r-xp 00000000 fd:01 201348055 /usr/lib/libpcre.so.1.2.0 f6fc0000-f6fc2000 r--p 00061000 fd:01 201348055 /usr/lib/libpcre.so.1.2.0 f6fc2000-f6fc3000 rw-p 00063000 fd:01 201348055 /usr/lib/libpcre.so.1.2.0 f6fc3000-f6fcf000 r-xp 00000000 fd:01 202740809 /usr/lib/libdrm.so.2.4.0 f6fcf000-f6fd0000 r--p 0000b000 fd:01 202740809 /usr/lib/libdrm.so.2.4.0 f6fd0000-f6fd1000 rw-p 0000c000 fd:01 202740809 /usr/lib/libdrm.so.2.4.0 f6fd1000-f6fd5000 r-xp 00000000 fd:01 202740799 /usr/lib/libXxf86vm.so.1.0.0 f6fd5000-f6fd6000 r--p 00004000 fd:01 202740799 /usr/lib/libXxf86vm.so.1.0.0 f6fd6000-f6fd7000 rw-p 00005000 fd:01 202740799 /usr/lib/libXxf86vm.so.1.0.0 f6fd7000-f6fd8000 r-xp 00000000 fd:01 201522922 /usr/lib/libxshmfence.so.1.0.0 f6fd8000-f6fd9000 r--p 00000000 fd:01 201522922 /usr/lib/libxshmfence.so.1.0.0 f6fd9000-f6fda000 rw-p 00001000 fd:01 201522922 /usr/lib/libxshmfence.so.1.0.0 f6fda000-f6ffd000 r-xp 00000000 fd:01 202740769 /usr/lib/libxcb.so.1.1.0 f6ffd000-f6ffe000 r--p 00022000 fd:01 202740769 /usr/lib/libxcb.so.1.1.0 f6ffe000-f6fff000 rw-p 00023000 fd:01 202740769 /usr/lib/libxcb.so.1.1.0 f6fff000-f7004000 r-xp 00000000 fd:01 201522899 /usr/lib/libxcb-sync.so.1.0.0 f7004000-f7005000 r--p 00005000 fd:01 201522899 /usr/lib/libxcb-sync.so.1.0.0 f7005000-f7006000 rw-p 00006000 fd:01 201522899 /usr/lib/libxcb-sync.so.1.0.0 f7006000-f7009000 r-xp 00000000 fd:01 201522895 /usr/lib/libxcb-shape.so.0.0.0 f7009000-f700a000 r--p 00002000 fd:01 201522895 /usr/lib/libxcb-shape.so.0.0.0 f700a000-f700b000 rw-p 00003000 fd:01 201522895 /usr/lib/libxcb-shape.so.0.0.0 f700b000-f7014000 r-xp 00000000 fd:01 201522889 /usr/lib/libxcb-render.so.0.0.0 f7014000-f7015000 r--p 00008000 fd:01 201522889 /usr/lib/libxcb-render.so.0.0.0 f7015000-f7016000 rw-p 00009000 fd:01 201522889 /usr/lib/libxcb-render.so.0.0.0 f7016000-f701d000 r-xp 00000000 fd:01 201522905 /usr/lib/libxcb-xfixes.so.0.0.0 f701d000-f701e000 r--p 00006000 fd:01 201522905 /usr/lib/libxcb-xfixes.so.0.0.0 f701e000-f701f000 rw-p 00007000 fd:01 201522905 /usr/lib/libxcb-xfixes.so.0.0.0 f701f000-f702c000 r-xp 00000000 fd:01 201522885 /usr/lib/libxcb-randr.so.0.1.0 f702c000-f702d000 r--p 0000d000 fd:01 201522885 /usr/lib/libxcb-randr.so.0.1.0 f702d000-f702e000 rw-p 0000e000 fd:01 201522885 /usr/lib/libxcb-randr.so.0.1.0 f702e000-f7030000 r-xp 00000000 fd:01 201522883 /usr/lib/libxcb-present.so.0.0.0 f7030000-f7031000 r--p 00001000 fd:01 201522883 /usr/lib/libxcb-present.so.0.0.0 f7031000-f7032000 rw-p 00002000 fd:01 201522883 /usr/lib/libxcb-present.so.0.0.0 f7032000-f7034000 r-xp 00000000 fd:01 203140423 /usr/lib/libxcb-dri3.so.0.0.0 f7034000-f7035000 r--p 00001000 fd:01 203140423 /usr/lib/libxcb-dri3.so.0.0.0 f7035000-f7036000 rw-p 00002000 fd:01 203140423 /usr/lib/libxcb-dri3.so.0.0.0 f7036000-f703a000 r-xp 00000000 fd:01 203140421 /usr/lib/libxcb-dri2.so.0.0.0./pharo-ui: line 11: 4019 Aborted (core dumped) "$DIR"/"pharo-vm/pharo" "$@"
-- Mariano http://marianopeck.wordpress.com
On Gentoo the image freeze and I see that in the terminal: *** Error in `/home/jecisc/.local/share/Pharo/spurVM/pharo': free(): invalid next size (fast): 0x08c87ed8 *** -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France
participants (7)
-
Ben Coman -
Eliot Miranda -
Esteban Lorenzano -
Ferlicot D. Cyril -
Mariano Martinez Peck -
Max Leske -
Nicolai Hess