[Pharo-dev] VM crash in Pharo 8.0 during save

Shaping shaping at uurda.org
Fri May 31 07:18:50 EDT 2019



From: Pharo-dev [mailto:pharo-dev-bounces at lists.pharo.org] On Behalf Of Ben Coman
Sent: Friday, May 31, 2019 04:39
To: Pharo Development List <pharo-dev at 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 at uurda.org <mailto:shaping at 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:

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?




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20190531/07a1f9e5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 11708 bytes
Desc: not available
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20190531/07a1f9e5/attachment.png>

More information about the Pharo-dev mailing list