Smalltalk › Pharo › Pharo Smalltalk Developers

VM crash in Pharo 8.0 during save

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Shaping1

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

crash.dmp (17K) Download Attachment

Ben Coman

Re: VM crash in Pharo 8.0 during save

On Wed, 29 May 2019 at 21:21, Shaping <[hidden email]> 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

Shaping1

Re: VM crash in Pharo 8.0 during save

From: Pharo-dev [mailto:[hidden email]] On Behalf Of Ben Coman
Sent: Friday, May 31, 2019 04:39
To: Pharo Development List <[hidden email]>
Subject: Re: [Pharo-dev] VM crash in Pharo 8.0 during save

On Wed, 29 May 2019 at 21:21, Shaping <[hidden email]> 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"

> 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

ducasse

Re: VM crash in Pharo 8.0 during save

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

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