From: Pharo-dev [mailto:[email protected]] On Behalf Of Ben
Coman
Sent: Friday, May 31, 2019 04:39
To: Pharo Development List <[email protected]>
Subject: Re: [Pharo-dev] VM crash in Pharo 8.0 during save
On Wed, 29 May 2019 at 21:21, Shaping <[email protected]
<mailto:[email protected]> > 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
