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) 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.
Hi Igor,
On Mon, Aug 6, 2012 at 6:50 AM, Igor Stasenko siguctua@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?
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.
On 6 August 2012 20:09, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Igor,
On Mon, Aug 6, 2012 at 6:50 AM, Igor Stasenko siguctua@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
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@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@gmail.com wrote:
On 6 August 2012 20:09, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Igor,
On Mon, Aug 6, 2012 at 6:50 AM, Igor Stasenko siguctua@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.
Hi elliot
if I understand correctly this new special allocate does not raise a gc before allocating new objects and I was wondering what is the logic behind. How can you guarantee that there is still enough space when allocating an object?
Stef
vm-dev@lists.squeakfoundation.org