[Vm-dev] [Pharo-dev] More Windows VM Crashing -_-

[Eliot Miranda]

Hi Peter,

> On Mar 22, 2017, at 2:31 AM, Peter Uhnak <i.uhnak at gmail.com> wrote:
> 
> Hi,
> 
> Originally I thought my VM is crashing because of FT, so I applied some fix from FogBugz (that is now part of Pharo 6), but that didn't help.
> 
> So I disabled FT in settings and changed fonts to non-FT ones; didn't help.
> So I completely removed FT2Plugin.dll (now settings just states that FT fonts are not available), but that didn't help either.
> 
> And obviously there is no crash.dmp whatsoever (this is latest Windows VM).
> 
> This crash is extremely frustrating because the crash happens _during saving_, which means I am losing code all the time and have to constantly recover them, which really makes my blood boil.
> 
> Without crash dump I don't even know where and how to start investigating. Windows kindly opens Visual Studio when Pharo crashes, but all it shows to me is assembly, which is not very useful to me. I can somewhat orient myself in the C code of the VM (as I've alredy fixed some other issues in the VM), but here I am lost.
> 
> <SNIP>
> 00407D7F  ret  
> 00407D80  mov         eax,dword ptr ds:[00596E44h]  
> 00407D85  test        al,3  
> 00407D87  jne         00407DB2  
> 00407D89  mov         ecx,dword ptr ds:[596E08h]  
> 00407D8F  lea         edx,[ecx-1]  
> 00407D92  cmp         eax,edx  
> 00407D94  jb          00407DB2  
> 00407D96  cmp         dword ptr ds:[596E10h],eax  
> 00407D9C  jb          00407DB2  
> 00407D9E  mov         ecx,dword ptr ds:[5B89D0h]  
> 00407DA4  cmp         dword ptr [eax-4],ecx  
> 00407DA7  jb          00407DB2  
> 00407DA9  mov         eax,dword ptr ds:[00596E28h]  
> ---> 00407DAE  movzx       eax,byte ptr [eax]  
> 00407DB1  ret  
> 
> eax = 00000000
> ecx = 04700000
> </SNIP>

Can you post a link to the exact VM you're using?  I may be able to make sense of this.

First, I'm very sorry you're experiencing these crashes.  They're likely a bug in the new compactor.  It makes multiple compaction passes when there are lots of objects, only on snapshot.  In a normal GC it only ever makes one pass.

Therefore, one thing that may allow you to work around the bug is to modify the snapshot:andQuit: method to explicitly do a Smalltalk garbageCollect before invoking the snapshot primitive.  If the bug is only on subsequent passes then the explicit GC should not crash and will make it much less likely that the GC done as part of the snapshot will require a second pass, and hence less likely to crash.

> So my question I guess is:
> How can we fix this? How can I help fix this? Because I've lost countless days of time and energy on this f***ing problem...

Helping me match the code above with the VM will be really helpful.  I want to know the values in registers, and the value of nilObj too.

> Peter

_,,,^..^,,,_ (phone)