- Pharo-dev - lists.pharo.org

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

by Ben Coman

On Sat, Jan 9, 2016 at 7:12 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > 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 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_… >>

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Ferlicot D. Cyril

Le 08/01/2016 21:22, stepharo a Ã©crit : > I'm sorry but this debugger should not be the default one. > MONDAY we are filming our mooc and we have to explain the debugger and > personally I do not see the gain: > - It looks a lot more complex to me and I do not want to have to > redo all the screenshots > of our lecture. > - Just that I have to learn the meaning of small icons. > - Why do we need a special pane for the evaluator > - Why there is a type column. > - Sorry but I'm not convinced about the moldable aspect behind the > story (no need to argue I know it) > > I would like to avoid to be forced to use not the latest version of > Pharo for the mooc. > > Such changes are arriving far too late in the release. We do not change > the debugger itself the day of code freeze. > > We decided that the GTDebugger can be included but to me it never meant > that it should be the default one. > I think that experts can choose the debugger they want. The newbies don't. > > Stef > > IMO the old debugger is way more intuitive. When I used the debugger of Eclipse for java I was lost. When I used Spec debugger I thought "Oh, this is not so hard in fact". And I lose the feeling with GTDebugger. And the debugger is one of the main source of interest for newbies. Maybe we could have a button on the spec Debugger "Switch to GTDebugger"? -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Jan. 9, 2016

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

by Mariano Martinez Peck

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(a)gmail.com> wrote: > > > 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 > -- Mariano http://marianopeck.wordpress.com

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Ben Coman

On Sat, Jan 9, 2016 at 4:22 AM, stepharo <stepharo(a)free.fr> wrote: > I'm sorry but this debugger should not be the default one. > MONDAY we are filming our mooc and we have to explain the debugger and > personally I do not see the gain: > - It looks a lot more complex to me and I do not want to have to redo > all the screenshots > of our lecture. > - Just that I have to learn the meaning of small icons. > - Why do we need a special pane for the evaluator > - Why there is a type column. > - Sorry but I'm not convinced about the moldable aspect behind the story > (no need to argue I know it) This also applies to UPBE. It would be good to get that out the door matching Pharo 5 without too much rework. cheers -ben > I would like to avoid to be forced to use not the latest version of Pharo > for the mooc. > > Such changes are arriving far too late in the release. We do not change the > debugger itself the day of code freeze. > > We decided that the GTDebugger can be included but to me it never meant that > it should be the default one. > I think that experts can choose the debugger they want. The newbies don't. > > Stef > >

Jan. 9, 2016

Re: [Pharo-dev] Semaphore and Mutex changes summary

by Ben Coman

I found the blogs by real-time OS guys (RTOS) have more interesting opinions on the finer points. They are the ones who are down in the trenches. cheers -ben On Sat, Jan 9, 2016 at 4:17 AM, stepharo <stepharo(a)free.fr> wrote: > thanks for the summary. > I think that this is important to update the class comments with the comment > of ben. > I read several blogs of mutex vs semaphore and this is nice to get this > cleared out. > > Stef > > Le 7/1/16 14:05, Denis Kudriashov a Ã©crit : > > Hi. > > We got interesting discussion about semaphore and mutex. Here I put summary > of proposed changes. > > First we will deprecate Semaphore>>forMutualExclusion and rename it to > Semaphore>>newSignalled. Explanation from Ben Coman: > >> Semaphore>>forMutualExclusion *encourages* people to believe >> semaphores can be used *on*their*own* for mutual exclusion, when they >> *shouldn't*. You *must* add ownership. If the mutual exclusion >> object doesnât have ownership then, irrelevant of what it is called, >> it is not a mutex!!! [1]. > > And more: >> >> With an implementation like.. >> Semaphore>>forMutualExclusion >> ^self new signal >> we don't gain a lot, and its a misleading convenience method since its >> doesn't provide the proper facility for mutual exclusion (and I do >> conflate mutual exclusion == mutex). Indeed, "Semaphore >> forMutualExclusion + roll your ownership management + problems since >> you weren't aware you needed to roll your own ownership management" is >> not more convenient than "Mutex new" >> If you want to keep a convenience method for a pre signalled >> Semaphore, then we could provide something like "Semaphore >> newSignalled" > > > It is also explain why we should deprecate Semaphore>>critical: and use > Mutex>>critical: instead. That's second change. > > So we want to move 4 Semaphore methods to Mutex: > > critical: mutuallyExcludedBlock > > It will relies on new Semaphore method waitIfInterrupted: which block is > executed when waiting process terminated at point where lock was not > acquired. Slice for this already in inbox. > > critical: mutuallyExcludedBlock ifCurtailed: terminationBlock > critical: mutuallyExcludedBlock ifError: errorBlock > > Semantic of this method is like BlockCosure>>ifError:. It culls error > properties to handler block. It will be changed to cull only error instance. > It will touch WeakArray and WeakRegistry. Now they doing this: > > ifError:[:msg :rcvr| rcvr error: msg]. > > > No special logic inside handler. So we will just use #critical: message. > > critical: mutuallyExcludedBlock ifLocked: alternativeBlock > > It purpose looks like "enter critical section without waiting otherwise > alternativeBlock". But implementation not shows that waiting can not be > happens: > > critical: mutuallyExcludedBlock ifLocked: alternativeBlock > excessSignals == 0 > ifTrue: > [ ^alternativeBlock value ]. > ^self critical: mutuallyExcludedBlock > > When critical message is sent but it method not started interrupt can happen > and other process can lock this semaphore. And when process will be resumed > it will be blocked. > So implementation is not correct to me. It should be changed somehow. > > Welcome for suggestions > > >

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 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