January 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Re: problem with become:?

by Eliot Miranda

Hi Doru, Hi Nicolai, On Fri, Jan 8, 2016 at 4:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Doru, Hi Nicolai, > > On Fri, Jan 8, 2016 at 2:33 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> >> >> On Fri, Jan 8, 2016 at 2:11 PM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> >>> >>> >>> >>> 2016-01-08 23:09 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>>> Hi Doru, >>>> >>>> On Fri, Jan 8, 2016 at 12:02 PM, Tudor Girba <tudor(a)tudorgirba.com> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> If I execute the following code in the latest Pharo image: >>>>> >>>>> Object subclass: #A >>>>> instanceVariableNames: '' >>>>> classVariableNames: '' >>>>> package: 'AA'. >>>>> Object subclass: #B >>>>> instanceVariableNames: '' >>>>> classVariableNames: '' >>>>> package: 'AA'. >>>>> a := A new. >>>>> b := B new. >>>>> a become: b. >>>>> a class >>>>> >>>>> ==> âA". >>>>> >>>>> In a pre-Spur image, I used to get âBâ. Is this a bug, or is there a >>>>> change I am not aware of? >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>> >>>> Looks like a bug to me. I'll fix it asap. >>>> >>> >>> >>> There is another bug report at >>> http://bugs.squeak.org/view.php?id=7845 >>> >>> | obj1 obj2 | >>> obj1 := 'string'. >>> obj2 := 1.234. >>> obj1 become: obj2. >>> {obj1. obj2} "=> #('X9 LÃvÂ¾' 'string'). it should be #(1.234 'string') " >>> >>> Squeak Cog Supr Virtual Machine 4.0.3427.0 >>> >>> >>> Is it related? >>> >> >> Thank you, certainly looks like it. >> > > The good news is that these are not bugs in the simulator. So I need to > generate new sources and working VMs (and Esteban will need to rebuild the > Pharo 5 VM) and then the bugs should be fixed. There's a slim possibility > that this could be due to a Slang bug but I doubt it. > Shows why I know. It is indeed a Slang bug, and one that shows itself only under optimisation above -O1, i.e. neither the debug nor assert VMs show the bug :-(. Alas these are the kind of bugs that take a while to track down. I'm on it though. -- >>>>> www.tudorgirba.com >>>>> www.feenk.com >>>>> >>>>> "Things happen when they happen, >>>>> not when you talk about them happening." >>>> >>>> >>>> _,,,^..^,,,_ >>>> best, Eliot >>>> >>>> _,,,^..^,,,_ >> best, Eliot >> > > _,,,^..^,,,_ > best, Eliot > -- _,,,^..^,,,_ best, Eliot

Jan. 9, 2016

Re: [Pharo-dev] Help with FFI crash in latest Spur (only in Linux)

by Mariano Martinez Peck

On Fri, Jan 8, 2016 at 8:41 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2016-01-09 0:12 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> On Jan 8, 2016 4:13 PM, "Ben Coman" <btc(a)openinworld.com> wrote: >> > >> > On Sat, Jan 9, 2016 at 2:04 AM, Mariano Martinez Peck >> > <marianopeck(a)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_… >> > >> > > -- Mariano http://marianopeck.wordpress.com

Jan. 9, 2016

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Re: problem with become:?

by Eliot Miranda

Hi Doru, Hi Nicolai, On Fri, Jan 8, 2016 at 2:33 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, Jan 8, 2016 at 2:11 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> >> >> >> 2016-01-08 23:09 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> Hi Doru, >>> >>> On Fri, Jan 8, 2016 at 12:02 PM, Tudor Girba <tudor(a)tudorgirba.com> >>> wrote: >>> >>>> Hi, >>>> >>>> If I execute the following code in the latest Pharo image: >>>> >>>> Object subclass: #A >>>> instanceVariableNames: '' >>>> classVariableNames: '' >>>> package: 'AA'. >>>> Object subclass: #B >>>> instanceVariableNames: '' >>>> classVariableNames: '' >>>> package: 'AA'. >>>> a := A new. >>>> b := B new. >>>> a become: b. >>>> a class >>>> >>>> ==> âA". >>>> >>>> In a pre-Spur image, I used to get âBâ. Is this a bug, or is there a >>>> change I am not aware of? >>>> >>>> Cheers, >>>> Doru >>>> >>> >>> Looks like a bug to me. I'll fix it asap. >>> >> >> >> There is another bug report at >> http://bugs.squeak.org/view.php?id=7845 >> >> | obj1 obj2 | >> obj1 := 'string'. >> obj2 := 1.234. >> obj1 become: obj2. >> {obj1. obj2} "=> #('X9 LÃvÂ¾' 'string'). it should be #(1.234 'string') " >> >> Squeak Cog Supr Virtual Machine 4.0.3427.0 >> >> >> Is it related? >> > > Thank you, certainly looks like it. > The good news is that these are not bugs in the simulator. So I need to generate new sources and working VMs (and Esteban will need to rebuild the Pharo 5 VM) and then the bugs should be fixed. There's a slim possibility that this could be due to a Slang bug but I doubt it. -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Things happen when they happen, >>>> not when you talk about them happening." >>> >>> >>> _,,,^..^,,,_ >>> best, Eliot >>> >>> _,,,^..^,,,_ > best, Eliot > _,,,^..^,,,_ best, Eliot

Jan. 9, 2016

Re: [Pharo-dev] Help with FFI crash in latest Spur (only in Linux)

by Ferlicot D. Cyril

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_… > > > * > * > **** 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

Jan. 8, 2016

Re: [Pharo-dev] Help with FFI crash in latest Spur (only in Linux)

by Nicolai Hess

2016-01-09 0:12 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > On Jan 8, 2016 4:13 PM, "Ben Coman" <btc(a)openinworld.com> wrote: > > > > On Sat, Jan 9, 2016 at 2:04 AM, Mariano Martinez Peck > > <marianopeck(a)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_… > > >

Jan. 8, 2016

Re: [Pharo-dev] Help with FFI crash in latest Spur (only in Linux)

by Mariano Martinez Peck

On Jan 8, 2016 4:13 PM, "Ben Coman" <btc(a)openinworld.com> wrote: > > On Sat, Jan 9, 2016 at 2:04 AM, Mariano Martinez Peck > <marianopeck(a)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_… >

Jan. 8, 2016

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Re: problem with become:?

by Eliot Miranda

On Fri, Jan 8, 2016 at 2:11 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-01-08 23:09 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Hi Doru, >> >> On Fri, Jan 8, 2016 at 12:02 PM, Tudor Girba <tudor(a)tudorgirba.com> >> wrote: >> >>> Hi, >>> >>> If I execute the following code in the latest Pharo image: >>> >>> Object subclass: #A >>> instanceVariableNames: '' >>> classVariableNames: '' >>> package: 'AA'. >>> Object subclass: #B >>> instanceVariableNames: '' >>> classVariableNames: '' >>> package: 'AA'. >>> a := A new. >>> b := B new. >>> a become: b. >>> a class >>> >>> ==> âA". >>> >>> In a pre-Spur image, I used to get âBâ. Is this a bug, or is there a >>> change I am not aware of? >>> >>> Cheers, >>> Doru >>> >> >> Looks like a bug to me. I'll fix it asap. >> > > > There is another bug report at > http://bugs.squeak.org/view.php?id=7845 > > | obj1 obj2 | > obj1 := 'string'. > obj2 := 1.234. > obj1 become: obj2. > {obj1. obj2} "=> #('X9 LÃvÂ¾' 'string'). it should be #(1.234 'string') " > > Squeak Cog Supr Virtual Machine 4.0.3427.0 > > > Is it related? > Thank you, certainly looks like it. -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Things happen when they happen, >>> not when you talk about them happening." >>> >>> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> >> >> >> > > -- _,,,^..^,,,_ best, Eliot

Jan. 8, 2016

Re: [Pharo-dev] [Pharo-users] [ann] gtdebugger in pharo 5.0

by Tudor Girba

Hi, Thanks a lot for the detailed feedback. > On Jan 8, 2016, at 7:28 PM, Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>> wrote: > > Hi, > > with a moldable debugger we should (in the future) be able to support > debugging also different/other programming languages/DSLs in Pharo :) Yes. This would work quite well if the language would project on the AST of Pharo, like Helvetia does. > - although usually one does necessary have such a use case. So I guess > GTInspector or other will be adopted to own needs more than GTDebugger. The debugger can be specialized for specific libraries or frameworks, not only languages. For example, we currently have extensions for PetitParser, Glamour, Announcements and they are meaningful. > However: > The only objection so far is that I dislike the order/size of the panes. That is actually encouraging :). > The placement of the panes in GTDebugger (as for instance found in Moose) > requires often to use the scrollbars of the pane showing the stack because > of the text length. The horizontal bar could also be prevented by making the items in the list wrapped (so, they might occupy multiple lines). > In GTDebugger the stack is at the top left, the source at the top right with > a common splitter beneath the two panes: therefore the height (depth) of the > stack pane is always the height of the code pane. > When you have a long method to debug on the right much space is wasted for > a deep stack on the left although you might only be interested in a few top frames. > > Contrary when you have are interested in a deep/full stack and you increase the > height of the stack pane on the left you directly increase the height of the code > pane and for short methods you waste a lot of space in the source pane as well. The reason for this choice was to expose the developer to more of the stack, but it is not an essential design choice. > This is much better solved with the positioning in the traditinal Debugger: > - Stack > - Source > - other > > So in my opinion We should preserve: > > - TOP: the stack at the top (using the full width of the window, so only vertical scrolling > has to be done to "roll" on the stack, no need for horizontal scrolling as the area > is wide enough) > - MIDDLE: the source code pane in the middle (also using the full width of the window and there > fore in alignment with code pane in the the usual tools like Nautilus, change sorter, ...) > - BOTTON: one or more panel for inspection at the bottom We will play with this a bit. Or does anyone else would like to give it a try? > It would be OK for me if others like the new layout better - but at least there should be an > option to support the traditional layout as well (or support pane movemen/docking as in other IDEs) Movement would be certainly interesting and I would be happy if someone would implement this in Morphic. > Also the debugger window in Moose wastes a lot of space/has unused space within the > windows client are itself. For instance the splitters are very thick which might be an issue of > the moose theme. Itâs actually an issue in Glamour, but it can be adapted. Cheers, Doru > Thanks > T. > > Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr > Von: "Tudor Girba" <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>>, "Moose-dev Moose Dev" <moose-dev(a)iam.unibe.ch <mailto:moose-dev@iam.unibe.ch>>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> > Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0 > > Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a significant change that might affect your workflow, here is some background information to help you deal with the change. > > First, you should know that the change is not irreversible and it is easily possible to disabled the new debugger through a setting. However, please do take the time to provide us feedback if something does not work out for you. We want to know what can be improved and we try to react as fast as we can. > > A practical change comes from the fact that the variables are manipulated through a GTInspector, which makes it cheaper to maintain in the longer run. > > > While the first thing that will capture the attention is the default generic interface, the real power comes from the moldable nature of the debugger. Like all other GT tools, GTDebugger is also moldable by design. This means that we can construct custom debuggers for specific libraries at small costs (often measured in a couple of hundred lines of code). > > > > Here is an introductory overview blog post that also includes some links for further reading: > http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ <http://www.humane-assessment.com/blog/gtdebugger-in-pharo/> > > Please let us know what you think. > > Cheers, > Doru > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/>[http://www.tudorgirba.com <http://www.tudorgirba.com/>] > www.feenk.com <http://www.feenk.com/>[http://www.feenk.com <http://www.feenk.com/>] > > "Beauty is where we see it." -- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/> "Presenting is storytelling."

Jan. 8, 2016

Re: [Pharo-dev] GTDebugger (case 17341 Integrate GTools version 3.3)

by Tudor Girba

This is a fun one. I think the reason comes from incorrect printing as comment. Please open a bug for this. Cheers, Doru > On Jan 9, 2016, at 12:16 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-01-08 22:55 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-01-08 22:48 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-01-08 16:43 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > Hi Nicolai, > > Thanks for the feedback. > Some issues I'll manage to fix until we integrate. > For those that I do not manage please open bug reports. > > On Thu, Jan 7, 2016 at 9:13 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Some feedback on GTDebugger > > - The inspector pane is great, we can inspect, evaluate code, and easily show/ inspect the code (for thisContext). > although the evaluator pane has a bad text mode (for the thisContext). > > Can you give me more details? Maybe it's obvious but I'm missing what's wrong :) > > Hm, I can not reproduce it anymore. > > Ok, now it happened again. See screenshot, the thisContext evaluator pane is wrong. And it does > not go away (every debugger now shows this text, even if I debug a totally different method) > > How to reporduce: > > select some code and debugIt > in the debugger select > thisContex > select the Evaluator pane, now select the Source pane > close debugger > open debugger again > select Evaluator pane > -> it will always show the last source pane text in the Evaluator pane > > > > > > > Cheers, > Andrei > > - I think the buttons are too small and the icon for "stop over" is misleading, it looks like a "step out" > - the shortcuts (neither ctrl+t nor cmd+t) aren't working > - I find it totally annoying and useless that the context pane inspector scrolls away if you select a value in > the rightmost pane. The context inspector should be fixed. > - I really miss the "List Methods using 'varname'/List Methods storing into 'varname' > - the stacklist entry for block closures prints the block closure code, this is confusing (too much text for such a small widget). > > nicolai > > > > -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

Jan. 8, 2016

Re: [Pharo-dev] GTDebugger (case 17341 Integrate GTools version 3.3)

by Nicolai Hess

2016-01-08 22:55 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-01-08 22:48 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> >> >> 2016-01-08 16:43 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: >> >>> Hi Nicolai, >>> >>> Thanks for the feedback. >>> Some issues I'll manage to fix until we integrate. >>> For those that I do not manage please open bug reports. >>> >>> On Thu, Jan 7, 2016 at 9:13 PM, Nicolai Hess <nicolaihess(a)gmail.com> >>> wrote: >>> >>>> Some feedback on GTDebugger >>>> >>>> - The inspector pane is great, we can inspect, evaluate code, and >>>> easily show/ inspect the code (for thisContext). >>>> although the evaluator pane has a bad text mode (for the thisContext). >>>> >>> >>> Can you give me more details? Maybe it's obvious but I'm missing what's >>> wrong :) >>> >> >> Hm, I can not reproduce it anymore. >> > > Ok, now it happened again. See screenshot, the thisContext evaluator pane > is wrong. And it does > not go away (every debugger now shows this text, even if I debug a totally > different method) > How to reporduce: select some code and debugIt in the debugger select thisContex select the Evaluator pane, now select the Source pane close debugger open debugger again select Evaluator pane -> it will always show the last source pane text in the Evaluator pane > >> >> >> >>> >>> Cheers, >>> Andrei >>> >>> >>>> - I think the buttons are too small and the icon for "stop over" is >>>> misleading, it looks like a "step out" >>>> - the shortcuts (neither ctrl+t nor cmd+t) aren't working >>>> - I find it totally annoying and useless that the context pane >>>> inspector scrolls away if you select a value in >>>> the rightmost pane. The context inspector should be fixed. >>>> - I really miss the "List Methods using 'varname'/List Methods storing >>>> into 'varname' >>>> - the stacklist entry for block closures prints the block closure code, >>>> this is confusing (too much text for such a small widget). >>>> >>>> nicolai >>>> >>> >>> >> >

Jan. 8, 2016