[Vm-dev] [Cog] It seems like there's a bug
siguctua at gmail.com
Fri Aug 10 15:33:53 UTC 2012
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
899 int inVMThread =
#0 error (msg=0x54e7ae "out of memory") at
#1 0x00422c4c in eeInstantiateSmallClasssizeInBytes
#2 0x0044e8eb in interpret () at c:/COG/blessed/src/vm/gcc3x-cointerp.c:5712
#3 0x00450efc in enterSmalltalkExecutiveImplementation () at
#4 0x0045224a in initStackPagesAndInterpret () at
#5 0x0044aad1 in interpret () at c:/COG/blessed/src/vm/gcc3x-cointerp.c:1982
#6 0x00458f04 in sqMain (argc=1, argv=0x2a1018) at
#7 0x004591f8 in WinMain at 16 (hInst=0x400000, hPrevInstance=0x0,
lpCmdLine=0x292291 "", nCmdShow=10)
#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:
>>> 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
>>> as i understand it is an optimized version of
>>> 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 regards,
> Igor Stasenko.
More information about the Vm-dev