- Pharo-dev - lists.pharo.org

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

by Raffaello Giulietti

No, that does not work, as I reported: On 2017-05-03 10:33, Raffaello Giulietti wrote: > The current Pharo VM seems to support only the --memory option: I tried > with 1 and 2 GiB, nothing changes in the misbehavior. Further, Pharo crashes even when only *starting* with a JVM heap size of 16 MiB, a ridiculously small heap, regardless of the Pharo --memory option and the JVM max heap option. On 2017-05-03 10:55, Esteban Lorenzano wrote: > mmmâ¦ you can try assigning memory to pharo itself. > > --memory 1000m > > (for example) > > but it may happens that pharo + jvm exceeds the 2g max of a 32bits vm? > > Esteban > >> On 3 May 2017, at 10:52, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: >> >> OK, thanks, here it is: >> >> >> CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 >> VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> >> >> Seems what PharoConsole outputs, too. >> >> >> >> >> On 2017-05-03 10:49, Esteban Lorenzano wrote: >>> execute >>> Smalltalk vm version >>> in playground >>>> On 3 May 2017, at 10:47, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: >>>> >>>> Hi, >>>> >>>> how do I discover? >>>> >>>> I tried with Pharo.exe --version but this shows nothing. >>>> >>>> Conversely, with PharoConsole here is what I obtain. >>>> >>>>> C:\pharo6\PharoConsole.exe --version >>>> Win32 built on Apr 18 2017 19:55:47 GMT Compiler: 5.4.0 [Production Spur VM] >>>> CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 >>>> StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 >>>> VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ >>>> Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 2017-05-03 10:36, Esteban Lorenzano wrote: >>>>> Hi, >>>>> which vm version are you using? >>>>> Esteban >>>>>> On 2 May 2017, at 16:36, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: >>>>>> >>>>>> 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. >>>>>> >>>>>> 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

Re: [Pharo-dev] resizing the windows sometimes blocks the image

by Andrei Chis

Hi, On Wed, May 3, 2017 at 10:43 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hi > > Try resizing the window and clicking inside it a couple times. It usually > refreshes the surface correctly and avoids the need to force quit. > I tried to click a few time but nothing happened. Next time I'll try more :) > > I think it happens to other people too, it seems it's exclusive to Mac OS > X. > Most likely. I didn't had this problem on windows. Cheers, Andrei > Best, > > On Wed, May 3, 2017 at 10:23 AM, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> Hi, >> >> With the latest moose image based on Pharo 6 and vm (32 bit) sometimes >> when I resize the main window or enter full screen mode on MacOS the window >> becomes totally white and does not recover:[image: Inline image 1] >> I need to force quit the image. Also this happens not that often and >> quite randomly. >> >> Does this happen to anybody else or it's just me? >> >> Cheers, >> Andrei >> > >

May 3, 2017

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

by Esteban Lorenzano

mmmâ¦ you can try assigning memory to pharo itself. --memory 1000m (for example) but it may happens that pharo + jvm exceeds the 2g max of a 32bits vm? Esteban > On 3 May 2017, at 10:52, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: > > OK, thanks, here it is: > > > CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 > VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > > Seems what PharoConsole outputs, too. > > > > > On 2017-05-03 10:49, Esteban Lorenzano wrote: >> execute >> Smalltalk vm version >> in playground >>> On 3 May 2017, at 10:47, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: >>> >>> Hi, >>> >>> how do I discover? >>> >>> I tried with Pharo.exe --version but this shows nothing. >>> >>> Conversely, with PharoConsole here is what I obtain. >>> >>>> C:\pharo6\PharoConsole.exe --version >>> Win32 built on Apr 18 2017 19:55:47 GMT Compiler: 5.4.0 [Production Spur VM] >>> CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 >>> StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 >>> VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ >>> Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >>> >>> >>> >>> >>> >>> >>> On 2017-05-03 10:36, Esteban Lorenzano wrote: >>>> Hi, >>>> which vm version are you using? >>>> Esteban >>>>> On 2 May 2017, at 16:36, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: >>>>> >>>>> 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. >>>>> >>>>> 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

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

by Raffaello Giulietti

OK, thanks, here it is: CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Seems what PharoConsole outputs, too. On 2017-05-03 10:49, Esteban Lorenzano wrote: > execute > > Smalltalk vm version > > in playground > >> On 3 May 2017, at 10:47, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: >> >> Hi, >> >> how do I discover? >> >> I tried with Pharo.exe --version but this shows nothing. >> >> Conversely, with PharoConsole here is what I obtain. >> >>> C:\pharo6\PharoConsole.exe --version >> Win32 built on Apr 18 2017 19:55:47 GMT Compiler: 5.4.0 [Production Spur VM] >> CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 >> VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ >> Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> >> >> >> >> >> >> On 2017-05-03 10:36, Esteban Lorenzano wrote: >>> Hi, >>> which vm version are you using? >>> Esteban >>>> On 2 May 2017, at 16:36, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: >>>> >>>> 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. >>>> >>>> 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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60479 Home: https://github.com/pharo-project/pharo-core

May 3, 2017

[pharo-project/pharo-core] 1d7edd: 60479

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 1d7edd94bbc490de294a068fca16e42829b8ca1c https://github.com/pharo-project/pharo-core/commit/1d7edd94bbc490de294a068f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-05-03 (Wed, 03 May 2017) Changed paths: M GT-Debugger.package/GTDebuggerInspector.class/instance/building/compose.st M GT-Inspector.package/GTSimpleMethodsBrowser.class/instance/building/sourceOf_for_in_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60478.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60479.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60478.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60479.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-OSEnvironments.package/OSEnvironment.class/instance/accessing/getEnv_.st A System-OSEnvironments.package/OSEnvironment.class/instance/accessing/unsetEnv_.st A System-OSEnvironments.package/OSEnvironment.class/instance/private/getEnvViaFFI_.st R System-OSEnvironments.package/OSEnvironment.class/instance/private/getEnv_.st R System-OSEnvironments.package/OSEnvironment.class/instance/private/unsetEnv_.st A System-OSEnvironments.package/Win32Environment.class/instance/accessing/unsetEnv_.st A System-OSEnvironments.package/Win32Environment.class/instance/private/getEnvViaFFI_.st R System-OSEnvironments.package/Win32Environment.class/instance/private/getEnv_.st R System-OSEnvironments.package/Win32Environment.class/instance/private/unsetEnv_.st Log Message: ----------- 60479 20011 OSEnvironment>>getEnv: needs to use a primitive https://pharo.fogbugz.com/f/cases/20011 19936 The code presentation in the Meta tab cuts the scrollbar at the bottom https://pharo.fogbugz.com/f/cases/19936 19897 Problem with presentations containing tabulators in the inspector from the debugger https://pharo.fogbugz.com/f/cases/19897 http://files.pharo.org/image/60/60479.zip

May 3, 2017

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

by Esteban Lorenzano

execute Smalltalk vm version in playground > On 3 May 2017, at 10:47, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: > > Hi, > > how do I discover? > > I tried with Pharo.exe --version but this shows nothing. > > Conversely, with PharoConsole here is what I obtain. > > >C:\pharo6\PharoConsole.exe --version > Win32 built on Apr 18 2017 19:55:47 GMT Compiler: 5.4.0 [Production Spur VM] > CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 > VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ > Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > > > > > > On 2017-05-03 10:36, Esteban Lorenzano wrote: >> Hi, >> which vm version are you using? >> Esteban >>> On 2 May 2017, at 16:36, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: >>> >>> 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. >>> >>> 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

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

by Raffaello Giulietti

Hi, how do I discover? I tried with Pharo.exe --version but this shows nothing. Conversely, with PharoConsole here is what I obtain. >C:\pharo6\PharoConsole.exe --version Win32 built on Apr 18 2017 19:55:47 GMT Compiler: 5.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ On 2017-05-03 10:36, Esteban Lorenzano wrote: > Hi, > > which vm version are you using? > > Esteban > >> On 2 May 2017, at 16:36, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: >> >> 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. >> >> 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

Re: [Pharo-dev] resizing the windows sometimes blocks the image

by ClÃ©ment Bera

Hi Try resizing the window and clicking inside it a couple times. It usually refreshes the surface correctly and avoids the need to force quit. I think it happens to other people too, it seems it's exclusive to Mac OS X. Best, On Wed, May 3, 2017 at 10:23 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Hi, > > With the latest moose image based on Pharo 6 and vm (32 bit) sometimes > when I resize the main window or enter full screen mode on MacOS the window > becomes totally white and does not recover:[image: Inline image 1] > I need to force quit the image. Also this happens not that often and > quite randomly. > > Does this happen to anybody else or it's just me? > > Cheers, > Andrei >

May 3, 2017

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

by Esteban Lorenzano

Hi, which vm version are you using? Esteban > On 2 May 2017, at 16:36, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: > > 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. > > 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