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