[Vm-dev] [Cog] It seems like there's a bug

[Igor Stasenko]

I tried to insert fullGC() call before entering the interpreter loop ,
in hope that
it could reserve extra space on heap. but no changes..
still has this 'out of memory' when loading an image.

Here the backtrace:

Breakpoint 1, error (msg=0x54e7ae "out of memory") at
c:/COG/blessed/platforms/win32/vm/sqWin32Intel.c:899
899       int inVMThread =
ioOSThreadsEqual(ioCurrentOSThread(),getVMOSThread());
(gdb) bt
#0  error (msg=0x54e7ae "out of memory") at
c:/COG/blessed/platforms/win32/vm/sqWin32Intel.c:899
#1  0x00422c4c in eeInstantiateSmallClasssizeInBytes
(classPointer=271461816, sizeInBytes=16)
    at c:/COG/blessed/src/vm/gcc3x-cointerp.c:14431
#2  0x0044e8eb in interpret () at c:/COG/blessed/src/vm/gcc3x-cointerp.c:5712
#3  0x00450efc in enterSmalltalkExecutiveImplementation () at
c:/COG/blessed/src/vm/gcc3x-cointerp.c:14832
#4  0x0045224a in initStackPagesAndInterpret () at
c:/COG/blessed/src/vm/gcc3x-cointerp.c:18680
#5  0x0044aad1 in interpret () at c:/COG/blessed/src/vm/gcc3x-cointerp.c:1982
#6  0x00458f04 in sqMain (argc=1, argv=0x2a1018) at
c:/COG/blessed/platforms/win32/vm/sqWin32Intel.c:1406
#7  0x004591f8 in WinMain at 16 (hInst=0x400000, hPrevInstance=0x0,
lpCmdLine=0x292291 "", nCmdShow=10)
    at c:/COG/blessed/platforms/win32/vm/sqWin32Intel.c:1505
#8  0x0053c1c2 in main (argc=Cannot access memory at address 0xc000
) at ../mingw/main.c:73

On 6 August 2012 21:09, Igor Stasenko <siguctua at gmail.com> wrote:
> On 6 August 2012 20:09, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>> Hi Igor,
>>
>> On Mon, Aug 6, 2012 at 6:50 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>>>
>>>
>>> Hi, all
>>> there was an outstanding issue with running a 200MB Moose image on windows,
>>> the VM was simply crashed.
>>>
>>> I took a look and found that the problem is in:
>>>
>>> #eeInstantiateSmallClass:sizeInBytes:
>>>
>>> crashing (i guess)
>>
>>
>> How does it crash?
>>
>
> it crashes on self error: 'out of memory' in that method, because of
> condition not met.
> (youngstart is > memoryend) or something.. sorry don't have the code
> before my eyes right now)
>
>>
>>>
>>> at first few allocation once image loaded, because
>>> see the stack trace:
>>>
>>> Smalltalk stack dump:
>>>   0x1900dc I SmalltalkImage>clearExternalObjects 63367860: a(n) SmalltalkImage
>>>   0x190108 I SmalltalkImage>snapshot:andQuit: 63367860: a(n) SmalltalkImage
>>> 0x1007b820 s [] in WorldState class>saveSession
>>> 0x1007b87c s BlockClosure>ensure:
>>>
>>>
>>> so, i changed the last line in that method:
>>>
>>> -       ^self eeAllocate: sizeInBytes headerSize: hdrSize h1: header1 h2:
>>> header2 h3: 0
>>>
>>> +       ^  self allocate: sizeInBytes headerSize: hdrSize h1: header1 h2:
>>> header2 h3: 0 doFill: false format: 0
>>>
>>> and it is no longer crashes, and i were able to open and interact with
>>> that image..
>>> The VM works fine except from strange behavior with mouse cursor
>>> (which is always hidden unless you move & click the mouse), regardless
>>> of image you opened..
>>> So, it sounds like the dirty fix is is really dirty and incomplete (if
>>> it can be considered a fix at all).
>>>
>>> Then i recompiled again, and i don't know what is changed (should be
>>> nothing), but while VM are no longer crashes, it doesn't opens a main
>>> window ..
>>> it simply stalls somewhere with 0% CPU load..
>>> looks like problem with undelivered events/signals etc.. or some
>>> threads are unable to initialize properly.. .
>>>
>>> Back to
>>> #eeInstantiateSmallClass:sizeInBytes:
>>> as i understand it is an optimized version of
>>> #instantiateSmallClass:sizeInBytes:
>>> so, replacing it back with that method should be ok?
>>> Except that ee-one guarantees to not trigger GC but looking at senders
>>> of this message it looks like it is not necessary to guarantee that..
>>>
>>> But i worry that the real fix should be in completely different place,
>>> because i guess we observe only a consequence of another flaw: since
>>> that method allocates new object(s) it assumes that there's enough
>>> free space on heap..
>>> and since there's none.. this means that some of the logic is flawed
>>> in another place.
>>>
>>>
>>> Eliot, if you can take a look, i can send you that image in private
>>> mail, because it looks like it will be hard to reproduce.
>>> Image opens and works fine on mac.. but on windows we're getting these
>>> strange issues.
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>
>>
>>
>>
>> --
>> best,
>> Eliot
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.



-- 
Best regards,
Igor Stasenko.