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