VM crash in Pharo 8.0 during save
I made a few cosmetic changes (labels in Calypso). They were working fine. But they were not showing up in Iceberg as changes at some point. Iâd done some earlier tests with Iceberg, and was able to make dummy-method changes, and commit to the local GitHub repo. Everything seemed to work. At some indeterminate point, the changes I made were no longer showing in Iceberg. Further, when I would save, the image would save and quit automatically without actually saving. Iâd relaunch, reapply the changes in the change set (Epicea), and re-save with the same results. When I tried Save As⦠instead, I got the above crash. Also, after relaunch and on reapply, I noticed I was needing to proceed thru deprecated methods to get to a point where I could confirm all changes. AbstractListPresenter>>menu: is the deprecated method. It is hit 3 times after relaunch by the time I get to confirm the changes. The only unusual thing about this install is that I decided to put all on the RAID, not in Documents on the system drive. I had to premake the install folder in Program Files (x86), take ownership, and add permissions to get the install to work (to write files to the folder). (I would like the installer to be more graceful about installing to any folder on Windows. Can we make it so?) Canât run the .msi installer as admin and actually install. It brings up the command line options instead. As far as I can find, there are no Pharo-related files left in the user account/Documents area. I see something in the attached .dmp about a stack overflow. I would enter this bug at https://pharo.fogbugz.com/, but Iâm not sure it would get quick attention there. Shaping
On Wed, 29 May 2019 at 21:21, Shaping <shaping@uurda.org> wrote:
I made a few cosmetic changes (labels in Calypso). They were working fine. But they were not showing up in Iceberg as changes at some point.
Iâd done some earlier tests with Iceberg, and was able to make dummy-method changes, and commit to the local GitHub repo. Everything seemed to work. At some indeterminate point, the changes I made were no longer showing in Iceberg. Further, when I would save, the image would save and quit automatically without actually saving. Iâd relaunch, reapply the changes in the change set (Epicea), and re-save with the same results. When I tried Save As⦠instead, I got the above crash.
Looks like it crashed in a full garbage collection, which is something that is done when you are saving. Its been a while since I've seen one of those have been reported. Lately crashes have been more related to C libraries called by FFI. Exception code: C0000005 = "access violation" Exception addr: 0000000000433CD2 Access violation (read access) at FFFFFFFFFFFFFFFF VM Version: Cog Spur VM 5.0 (release) from Jan 5 2019 Compiler: gcc 4.2.1 Compatible Clang 5.0.1 (tags/RELEASE_501/final) Interpreter Build: CoInterpreter VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 Cogit Build: StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 Source Version: VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6 Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Primitive trace: <snip> at: primitiveGarbageCollect **FullGC** Smalltalk stack dump: 0xb8a948 I SmalltalkImage>garbageCollect 0x5e0aa10: a(n) SmalltalkImage 0xb8a990 I Bitmap class(Behavior)>handleFailingBasicNew: 0x64294d0: a(n) Bitmap class 0xb8a9d0 M Bitmap class(Behavior)>basicNew: 0x64294d0: a(n) Bitmap class 0xb8aa08 M Bitmap class(Behavior)>new: 0x64294d0: a(n) Bitmap class 0xb8aa68 I Bitmap class>decompressFromByteArray: 0x64294d0: a(n) Bitmap class 0xb6f320 M Form>unhibernate 0x9366dc8: a(n) Form
Iâve managed to crash the VM twice
Not a lot can be done by others until there is a reproducible case. You might run a debug-vm that would allow more analysis of a crash. Can you clarify you environment - OS Version, Pharo 32 or 64 bit ? (I would like the installer to be more graceful about installing to any
folder on Windows. Can we make it so?) Canât run the .msi installer as admin and actually install. It brings up the command line options instead. As far as I can find, there are no Pharo-related files left in the user account/Documents area.
You could have a go at adapting the installer to provide a concrete example of what you want. @all, where are the msi-installer sources?
I would enter this bug at https://pharo.fogbugz.com/, but Iâm not sure it would get quick attention there.
Bug tracking has moved to https://github.com/pharo-project/pharo/issues cheers -ben
From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Ben Coman Sent: Friday, May 31, 2019 04:39 To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] VM crash in Pharo 8.0 during save On Wed, 29 May 2019 at 21:21, Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: I made a few cosmetic changes (labels in Calypso). They were working fine. But they were not showing up in Iceberg as changes at some point. Iâd done some earlier tests with Iceberg, and was able to make dummy-method changes, and commit to the local GitHub repo. Everything seemed to work. At some indeterminate point, the changes I made were no longer showing in Iceberg. Further, when I would save, the image would save and quit automatically without actually saving. Iâd relaunch, reapply the changes in the change set (Epicea), and re-save with the same results. When I tried Save As⦠instead, I got the above crash. Looks like it crashed in a full garbage collection, which is something that is done when you are saving. Its been a while since I've seen one of those have been reported. Lately crashes have been more related to C libraries called by FFI. Yes, that is what I expect. Exception code: C0000005 = "access violation" Exception addr: 0000000000433CD2 Access violation (read access) at FFFFFFFFFFFFFFFF VM Version: Cog Spur VM 5.0 (release) from Jan 5 2019 Compiler: gcc 4.2.1 Compatible Clang 5.0.1 (tags/RELEASE_501/final) Interpreter Build: CoInterpreter VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 Cogit Build: StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 Source Version: VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6 Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Primitive trace: <snip> at: primitiveGarbageCollect **FullGC** Smalltalk stack dump: 0xb8a948 I SmalltalkImage>garbageCollect 0x5e0aa10: a(n) SmalltalkImage 0xb8a990 I Bitmap class(Behavior)>handleFailingBasicNew: 0x64294d0: a(n) Bitmap class 0xb8a9d0 M Bitmap class(Behavior)>basicNew: 0x64294d0: a(n) Bitmap class 0xb8aa08 M Bitmap class(Behavior)>new: 0x64294d0: a(n) Bitmap class 0xb8aa68 I Bitmap class>decompressFromByteArray: 0x64294d0: a(n) Bitmap class 0xb6f320 M Form>unhibernate 0x9366dc8: a(n) Form
Iâve managed to crash the VM twice
Not a lot can be done by others until there is a reproducible case. You might run a debug-vm that would allow more analysis of a crash. Can you clarify you environment - OS Version, Pharo 32 or 64 bit ? Currently using an i7 laptop with 32 GB, running Windows 10 and Pharo 64-bit. Iâve a new tower that Iâm looking forward to move everything to, but thatâs a few days out. I will try to get a specific scenario carefully recorded so that someone can try this. Bug tracking has moved to https://github.com/pharo-project/pharo/issues Thatâs good to know. I put lots of GUI-related stuff in Fogbugz. Does Fogbugz stuff get moved automatically to /pharo/issues, or is Fogbugz being ignored now? Shaping
I will try to get a specific scenario carefully recorded so that someone can try this.
Thanks because we need reproducible cases to act.
Bug tracking has moved to https://github.com/pharo-project/pharo/issues <https://github.com/pharo-project/pharo/issues>
Thatâs good to know. I put lots of GUI-related stuff in Fogbugz. Does Fogbugz stuff get moved automatically to /pharo/issues, or is Fogbugz being ignored now?
We decided not to migrate and we ask for people to check what are the problems that they want to migrate. Remember that there is a new version of Spec and new widgets on the table. So we are probably fixing some problems and creating new ones :)
Shaping
participants (3)
-
Ben Coman -
ducasse -
Shaping