- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] PI'm promoting new stable VMs

by Alistair Grant

Hi Esteban, On 3 May 2017 at 13:22, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> On 3 May 2017, at 12:38, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi Esteban, >> >> $ curl http://get.pharo.org/64/60+vmLatest | bash >> $ ./pharo --version >> >> Shows the build version as: >> >> VM: 201705022326 https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> Date: Tue May 2 16:26:41 2017 -0700 $ >> >> Does that mean we should be building from the opensmalltalk repository >> instead of the pharo-vm repository (even temporarily)? > > officials VM for Pharo now are built using opensmalltalk-vm, yes. > we still keep our process for CI/testing purposes, though. Great, thanks for the clarification. Cheers, Alistair

May 3, 2017

Re: [Pharo-dev] PI'm promoting new stable VMs

by Thierry Goubier

Le 03/05/2017 Ã 22:39, Eliot Miranda a Ã©crit : > Hi Thierry, Hi Eliot, >> On May 3, 2017, at 1:20 PM, Thierry Goubier >> <thierry.goubier(a)gmail.com> wrote: >> >> I'm now chasing an old 64 bits vm from files.pharo.org. All the new >> ones for the past 2 months segfault. Would anybody have kept a ~ 2 >> month old 64 bits vm (threaded or not) for linux somewhere? > > I think the issue is not the version of the VM sources but the > version of GCC. Iconoile the 64-bit Linux VMs I build with GCC 4.4.x > and see no problems. Bintray uses 4.6.x and apparently segfaults. > Are you able to checkout opensmalltalk-vm and build your own 64-bit > Linux vm using GCC 4.4.x? You may have more success via this route. I'm on a system with gcc 6.3.0. The previous stable pharo vm is fine (20170212) so I'm back on it. None of the newest are, but I haven't done a bisect to tell you which number triggers the segfault. I do have random lockups with OSProcess on it, but they are cured with a Ctrl+., which is nice. I've never managed to get a home-compiled 64 bits vm to work without a segfault or a deadlock, so I've given up that path (*). Regards, Thierry (*) I've never managed to be sure I had all the dependencies right (i.e. tracking through the long log output and trying to make sure cover all the errors by loading the right package). I could compile the vm, and run it a bit (run a few image building commands) before hitting either a deadlock (OSProcess-related?) or a segfault. > HTH > >> >> Regards, >> >> Thierry >> >>> Le 03/05/2017 Ã 21:58, Nicolas Cellier a Ã©crit : >>> >>> >>> 2017-05-03 17:45 GMT+02:00 Eliot Miranda >>> <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: >>> >>> >>> >>>> On May 3, 2017, at 4:22 AM, Esteban Lorenzano >>>> <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>>> >>>> >>>>> On 3 May 2017, at 12:38, Alistair Grant >>>>> <akgrant0710(a)gmail.com <mailto:akgrant0710@gmail.com>> >>>>> wrote: >>>>> >>>>> Hi Esteban, >>>>> >>>>> $ curl http://get.pharo.org/64/60+vmLatest >>> <http://get.pharo.org/64/60+vmLatest> | bash >>>>> $ ./pharo --version >>>>> >>>>> Shows the build version as: >>>>> >>>>> VM: 201705022326 >>>>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git >>> <https://github.com/OpenSmalltalk/opensmalltalk-vm.git> >>>>> Date: Tue May 2 16:26:41 2017 -0700 $ >>>>> >>>>> Does that mean we should be building from the opensmalltalk >>>>> repository instead of the pharo-vm repository (even >>>>> temporarily)? >>>> >>>> officials VM for Pharo now are built using opensmalltalk-vm, >>>> yes. we still keep our process for CI/testing purposes, >>>> though. >>> >>> Woot! Thank you Esteban!! >>> >>> >>> +1 That will help us to help you, it's a win win. >>> >>> >>>> >>>> Esteban >>>> >>>>> >>>>> Thanks, Alistair >>>>> >>>>> >>>>>> On 3 May 2017 at 09:43, Esteban Lorenzano >>>>>> <estebanlm(a)gmail.com >>> <mailto:estebanlm@gmail.com>> wrote: >>>>>> in 15min, I will promote latest VM to stable VM. The new >>>>>> stable VM has a lot of bugfixes, notably: >>>>>> >>>>>> - compactor works - Cairo and Surface plugin now can >>>>>> coexist (and it does not crashes) - lot of other small >>>>>> things >>>>>> >>>>>> cheers, Esteban >>>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

May 3, 2017

Re: [Pharo-dev] PI'm promoting new stable VMs

by Eliot Miranda

Hi Thierry, > On May 3, 2017, at 1:20 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > I'm now chasing an old 64 bits vm from files.pharo.org. All the new ones for the past 2 months segfault. Would anybody have kept a ~ 2 month old 64 bits vm (threaded or not) for linux somewhere? I think the issue is not the version of the VM sources but the version of GCC. Iconoile the 64-bit Linux VMs I build with GCC 4.4.x and see no problems. Bintray uses 4.6.x and apparently segfaults. Are you able to checkout opensmalltalk-vm and build your own 64-bit Linux vm using GCC 4.4.x? You may have more success via this route. HTH > > Regards, > > Thierry > >> Le 03/05/2017 Ã 21:58, Nicolas Cellier a Ã©crit : >> >> >> 2017-05-03 17:45 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com >> <mailto:eliot.miranda@gmail.com>>: >> >> >> >> > On May 3, 2017, at 4:22 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> > >> > >> >> On 3 May 2017, at 12:38, Alistair Grant <akgrant0710(a)gmail.com <mailto:akgrant0710@gmail.com>> wrote: >> >> >> >> Hi Esteban, >> >> >> >> $ curl http://get.pharo.org/64/60+vmLatest >> <http://get.pharo.org/64/60+vmLatest> | bash >> >> $ ./pharo --version >> >> >> >> Shows the build version as: >> >> >> >> VM: 201705022326 https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> <https://github.com/OpenSmalltalk/opensmalltalk-vm.git> >> >> Date: Tue May 2 16:26:41 2017 -0700 $ >> >> >> >> Does that mean we should be building from the opensmalltalk repository >> >> instead of the pharo-vm repository (even temporarily)? >> > >> > officials VM for Pharo now are built using opensmalltalk-vm, yes. >> > we still keep our process for CI/testing purposes, though. >> >> Woot! Thank you Esteban!! >> >> >> +1 >> That will help us to help you, it's a win win. >> >> >> > >> > Esteban >> > >> >> >> >> Thanks, >> >> Alistair >> >> >> >> >> >>> On 3 May 2017 at 09:43, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> >>> in 15min, I will promote latest VM to stable VM. >> >>> The new stable VM has a lot of bugfixes, notably: >> >>> >> >>> - compactor works >> >>> - Cairo and Surface plugin now can coexist (and it does not crashes) >> >>> - lot of other small things >> >>> >> >>> cheers, >> >>> Esteban >> >>> >> >> >> > >> > >> >> > >

May 3, 2017

Re: [Pharo-dev] PI'm promoting new stable VMs

by Thierry Goubier

I'm now chasing an old 64 bits vm from files.pharo.org. All the new ones for the past 2 months segfault. Would anybody have kept a ~ 2 month old 64 bits vm (threaded or not) for linux somewhere? Regards, Thierry Le 03/05/2017 Ã 21:58, Nicolas Cellier a Ã©crit : > > > 2017-05-03 17:45 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com > <mailto:eliot.miranda@gmail.com>>: > > > > > On May 3, 2017, at 4:22 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > > > > >> On 3 May 2017, at 12:38, Alistair Grant <akgrant0710(a)gmail.com <mailto:akgrant0710@gmail.com>> wrote: > >> > >> Hi Esteban, > >> > >> $ curl http://get.pharo.org/64/60+vmLatest > <http://get.pharo.org/64/60+vmLatest> | bash > >> $ ./pharo --version > >> > >> Shows the build version as: > >> > >> VM: 201705022326 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > <https://github.com/OpenSmalltalk/opensmalltalk-vm.git> > >> Date: Tue May 2 16:26:41 2017 -0700 $ > >> > >> Does that mean we should be building from the opensmalltalk repository > >> instead of the pharo-vm repository (even temporarily)? > > > > officials VM for Pharo now are built using opensmalltalk-vm, yes. > > we still keep our process for CI/testing purposes, though. > > Woot! Thank you Esteban!! > > > +1 > That will help us to help you, it's a win win. > > > > > > Esteban > > > >> > >> Thanks, > >> Alistair > >> > >> > >>> On 3 May 2017 at 09:43, Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>> wrote: > >>> in 15min, I will promote latest VM to stable VM. > >>> The new stable VM has a lot of bugfixes, notably: > >>> > >>> - compactor works > >>> - Cairo and Surface plugin now can coexist (and it does not crashes) > >>> - lot of other small things > >>> > >>> cheers, > >>> Esteban > >>> > >> > > > > > >

May 3, 2017

Re: [Pharo-dev] PI'm promoting new stable VMs

by Nicolas Cellier

2017-05-03 17:45 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > On May 3, 2017, at 4:22 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > > > >> On 3 May 2017, at 12:38, Alistair Grant <akgrant0710(a)gmail.com> wrote: > >> > >> Hi Esteban, > >> > >> $ curl http://get.pharo.org/64/60+vmLatest | bash > >> $ ./pharo --version > >> > >> Shows the build version as: > >> > >> VM: 201705022326 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > >> Date: Tue May 2 16:26:41 2017 -0700 $ > >> > >> Does that mean we should be building from the opensmalltalk repository > >> instead of the pharo-vm repository (even temporarily)? > > > > officials VM for Pharo now are built using opensmalltalk-vm, yes. > > we still keep our process for CI/testing purposes, though. > > Woot! Thank you Esteban!! > > +1 That will help us to help you, it's a win win. > > > > Esteban > > > >> > >> Thanks, > >> Alistair > >> > >> > >>> On 3 May 2017 at 09:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >>> in 15min, I will promote latest VM to stable VM. > >>> The new stable VM has a lot of bugfixes, notably: > >>> > >>> - compactor works > >>> - Cairo and Surface plugin now can coexist (and it does not crashes) > >>> - lot of other small things > >>> > >>> cheers, > >>> Esteban > >>> > >> > > > > > >

May 3, 2017

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

by Raffaello Giulietti

On 2017-05-03 18:05, Denis Kudriashov wrote: > > 2017-05-03 16:28 GMT+02:00 Raffaello Giulietti > <raffaello.giulietti(a)lifeware.ch <mailto:raffaello.giulietti@lifeware.ch>>: > > Sorry, Phil, this is (currently) not open source software for many > reasons. Depending on how Pharo moves in the future, however, we > might consider opening it. > > > So you are not using JNIPort? > http://forum.world.st/ANN-JNIPort-for-Pharo-3-0-alpha-td4750750.html. > No, we have our own solution since more than 10 years. JNIPort seems old and it seems Pharo specific. Besides, in addition to Pharo we have to target and to maintain other two quite different environments. We want a similar architecture on all of them.

May 3, 2017

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

by Denis Kudriashov

2017-05-03 16:09 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > How could I load that JVM bridge? > > I am having a use case or two for that and was thinking that this was > not working with new Pharos. > I tried load JNIPort today. It is not loaded/working on Pharo6 because it is based on NativeBoost which is not supported by SpurVM. But I created suitable package which resolves missing classes. (in my test repo <http://smalltalkhub.com/#!/~dionisiy/DionisiyPlayground>). It should be loaded before JNI config. This is only thing I did. I not tested anything then

May 3, 2017

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

by Denis Kudriashov

2017-05-03 16:28 GMT+02:00 Raffaello Giulietti < raffaello.giulietti(a)lifeware.ch>: > Sorry, Phil, this is (currently) not open source software for many > reasons. Depending on how Pharo moves in the future, however, we might > consider opening it. So you are not using JNIPort? http://forum.world.st/ANN-JNIPort-for-Pharo-3-0-alpha-td4750750.html.

May 3, 2017

Re: [Pharo-dev] PI'm promoting new stable VMs

by Eliot Miranda

> On May 3, 2017, at 4:22 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 3 May 2017, at 12:38, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi Esteban, >> >> $ curl http://get.pharo.org/64/60+vmLatest | bash >> $ ./pharo --version >> >> Shows the build version as: >> >> VM: 201705022326 https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> Date: Tue May 2 16:26:41 2017 -0700 $ >> >> Does that mean we should be building from the opensmalltalk repository >> instead of the pharo-vm repository (even temporarily)? > > officials VM for Pharo now are built using opensmalltalk-vm, yes. > we still keep our process for CI/testing purposes, though. Woot! Thank you Esteban!! > > Esteban > >> >> Thanks, >> Alistair >> >> >>> On 3 May 2017 at 09:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> in 15min, I will promote latest VM to stable VM. >>> The new stable VM has a lot of bugfixes, notably: >>> >>> - compactor works >>> - Cairo and Surface plugin now can coexist (and it does not crashes) >>> - lot of other small things >>> >>> cheers, >>> Esteban >>> >> > >

May 3, 2017

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

by Raffaello Giulietti

Sorry, Phil, this is (currently) not open source software for many reasons. Depending on how Pharo moves in the future, however, we might consider opening it. On 2017-05-03 16:09, phil(a)highoctane.be wrote: > How could I load that JVM bridge? > > I am having a use case or two for that and was thinking that this was > not working with new Pharos. > > TIA > Phil > > On Wed, May 3, 2017 at 2:32 PM, Raffaello Giulietti > <raffaello.giulietti(a)lifeware.ch> wrote: >> Problem solved. >> >> The cause was a mismatch between a 0-based index and a 1-based index on >> copying arrays between Smalltalk and C. >> >> Rather confusingly, for some reason, FFI indices are 1-based even for C >> arrays, so that calling ExternalAddress>>byteAt:put:, for example, requires >> the index to be unnaturally 1-based. >> >> While I put a lot of care at this issue, a specific spot in the code was >> erroneous, leading to an improperly terminated C-style string which, in >> turn, caused the indirect crash of Pharo. >> >> My fault, however, neither Pharo's nor the JVM's. >> >> >> Thanks to all involved in replies. >> >> >> Greetings >> Raffaello >> >> >> >> On 2017-05-03 13:52, Ben Coman wrote: >>> >>> >>> >>> On Wed, May 3, 2017 at 4:33 PM, Raffaello Giulietti >>> <raffaello.giulietti(a)lifeware.ch <mailto:raffaello.giulietti@lifeware.ch>> >>> wrote: >>> >>> Unfortunately, as I just discovered, older versions of Pharo do not >>> support UFFI. I don't have the time (nor a real interest) in >>> backporting the code to an older pre-Spur VM which has probably >>> reached its EOL just for the sake of experimentation. It would >>> probably take hours to understand the older FFI model and to adapt >>> the code for no real advantage. >>> >>> The current Pharo VM seems to support only the --memory option: I >>> tried with 1 and 2 GiB, nothing changes in the misbehavior. >>> >>> I also tried the two heap-related JVM options in isolation, >>> unsuccessfully. Just for information, the current values for the >>> options are -Xms16m and -Xmx512m, meaning that the JVM heap should >>> start with 16 MiB and grow to a maximum size of 512 MiB, both of >>> which are rather modest values even for a 32 bit process. Besides, >>> they work in VisualWorks (32 bit). >>> >>> >>> What about tiny memory allocation like --memory 100m and -Xmx 100m ? >>> >>> Can you share some code that causes the crash? >>> >>> cheers -ben >>> >>> >>> The StackOverflow page indicated below is from year 2010, during the >>> age of Java 6. The JVM has undergone major changes since then, >>> including memory management, so I'm not sure the discussion there is >>> relevant for Java 8, the release we are targeting as of today. But >>> even if it were, I still cannot understand the crash in Pharo. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 2017-05-03 06:36, Ben Coman wrote: >>> >>> >>> >>> On Wed, May 3, 2017 at 12:30 AM, Denis Kudriashov >>> <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com> >>> <mailto:dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>>> >>> wrote: >>> >>> Could you check how it works with Pharo5 which was based on >>> prespur >>> CogVM? >>> >>> >>> Note, Pharo 5 Release was a Spur VM. >>> Try using... >>> http://files.pharo.org/get-files/50-preSpur/ >>> <http://files.pharo.org/get-files/50-preSpur/> >>> http://files.pharo.org/image/50-preSpur/50495.zip >>> <http://files.pharo.org/image/50-preSpur/50495.zip> >>> >>> or even Pharo 4. >>> >>> cheers -ben >>> >>> >>> 2017-05-02 16:36 GMT+02:00 Raffaello Giulietti >>> <raffaello.giulietti(a)lifeware.ch >>> <mailto:raffaello.giulietti@lifeware.ch> >>> <mailto:raffaello.giulietti@lifeware.ch >>> <mailto:raffaello.giulietti@lifeware.ch>>>: >>> >>> >>> Hello, >>> >>> I'm on Pharo 6 (32 bit)/Windows 10 (64 bit). >>> >>> I'm trying to load and use the (32 bit) JVM DLL into a >>> running >>> Pharo image via the UFFI. >>> >>> Everything works correctly, including JVM method >>> invocations, >>> except when trying to set the minimum and maximum JVM >>> heap size >>> by passing the -Xms<size> and -Xmx<size> options upon JVM >>> creation. With these options, Pharo simply crashes >>> without >>> leaving any trace. >>> >>> >>> Can you isolate whether the problem is either one of those, or >>> it happens with both, and if there is some cutoff where it >>> works? Also, perhaps try limiting heap being used by Pharo >>> --memory <size>[mk] use fixed heap size (added to >>> image size) >>> --mmap <size>[mk] limit dynamic heap size (default: >>> 1024m) [out 2G on 32-bit) >>> --maxoldspace <size>[mk] set max size of old space >>> memory to bytes >>> (disclaimer, I'm not too knowledgeable on these, just >>> pulled them from --help) >>> >>> Also consider that heap needs to be contiguous... >>> >>> **http://stackoverflow.com/questions/2457514/understanding-max-jvm-heap-size-32bit-vs-64bit >>> >>> <http://stackoverflow.com/questions/2457514/understanding-max-jvm-heap-size-…> >>> cheers -ben >>> >>> >>> Apparently, memory management requests from the JVM >>> interfere >>> with Pharo's own memory management. >>> >>> Please note that we successfully use the same mechanism >>> for both >>> VisualWorks (32 bit)/Windows 10 (64 bit) and Gemstone 64 >>> bit/Linux, so it seems it has to do with a Pharo >>> limitation somehow. >>> >>> Further, I couldn't find any documentation on how to >>> increase >>> Pharo's working set. >>> >>> So the questions are: >>> * What is the most probable cause of the crash >>> described above? >>> * Where is there more doc about Pharo's memory >>> configuration >>> settings? >>> >>> Greetings >>> Raffaello >>> >>> >>> >>> >>> >>> >>> >> >> >

May 3, 2017