Smalltalk › Cincom › VisualWorks

Help debugging VM crash

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 6 messages Options
cdavidshaffer
Reply | Threaded
Open this post in threaded view
♦
♦
|

Help debugging VM crash

cdavidshaffer
I have an application that reliably produces:

VisualWorks(R) 7.8 Download Mar 30, 2011
src/mman/mmScavenge.c:2188
Fatal error.
Out of memory.

under OSX-Snow Leopard.  The image doesn't grow much beyond 100Mb so I don't think that it is really a memory problem.  I'm trying to track down the problem but I'm out of my depth with VM-related problems.  I've tried to run in gdb:

--------------------------------------------------------------------------------------------------------------------
(gdb) b src/mman/mmScavenge.c:2188
Breakpoint 1 at 0x4b3cb: file src/mman/mmScavenge.c, line 2188.
(gdb) cont
Continuing.
[Switching to process 11847 thread 0x9703]

Breakpoint 1, emergencyTenureObject (oldOop=0x162e2e50, markOnTenure=0) at src/mman/mmScavenge.c:2188
2188 src/mman/mmScavenge.c: No such file or directory.
        in src/mman/mmScavenge.c
(gdb) bt
#0  emergencyTenureObject (oldOop=0x162e2e50, markOnTenure=0) at src/mman/mmScavenge.c:2188
#1  0x0004b47a in copyAndForward (oldOop=0x162e2e50, markOnTenure=0, objShouldBeTenured=0) at src/mman/mmScavenge.c:2231
#2  0x0004ba39 in scavengeRefBlock (currentRefPtr=0x1633673c, numRefs=0, markOnTenure=0) at src/mman/mmScavenge.c:2161
#3  0x0004bb1f in scavengeFutureSpace (currentOop=0x1633672c, markOnTenure=0) at src/mman/mmScavenge.c:1377
#4  0x0004bf57 in generationScavenger (additionalTenureFunc=0x27f, attemptTheScavenge=0, scavengePurpose=758304) at src/mman/mmScavenge.c:848
#5  0x0004d19d in scavengeNewSpace () at src/mman/mmScavenge.c:405
#6  0x00060aaf in handleSyncRequests () at src/stack/services.c:294
#7  0x00063f76 in rtAbortSend ()
Previous frame inner to this frame (gdb could not unwind past this frame)
--------------------------------------------------------------------------------------------------------------------

but that doesn't tell me much.  Anyone have a suggestion to help me sort this out?  If it is truly a memory problem, why don't I get the usual "out of space" notifier, for example?

David



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Boris Popov, DeepCove Labs (SNN)
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Help debugging VM crash

Boris Popov, DeepCove Labs (SNN)

David,

 

Try starting the VM with -xq switch as per below,

 

-Boris

 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of David Shaffer
Sent: Tuesday, January 10, 2012 9:47 AM
To: [hidden email]
Subject: [vwnc] Help debugging VM crash

 

I have an application that reliably produces:

 

VisualWorks(R) 7.8 Download Mar 30, 2011

src/mman/mmScavenge.c:2188

Fatal error.

Out of memory.

 

under OSX-Snow Leopard.  The image doesn't grow much beyond 100Mb so I don't think that it is really a memory problem.  I'm trying to track down the problem but I'm out of my depth with VM-related problems.  I've tried to run in gdb:

 

--------------------------------------------------------------------------------------------------------------------

(gdb) b src/mman/mmScavenge.c:2188

Breakpoint 1 at 0x4b3cb: file src/mman/mmScavenge.c, line 2188.

(gdb) cont

Continuing.

[Switching to process 11847 thread 0x9703]

 

Breakpoint 1, emergencyTenureObject (oldOop=0x162e2e50, markOnTenure=0) at src/mman/mmScavenge.c:2188

2188       src/mman/mmScavenge.c: No such file or directory.

                in src/mman/mmScavenge.c

(gdb) bt

#0  emergencyTenureObject (oldOop=0x162e2e50, markOnTenure=0) at src/mman/mmScavenge.c:2188

#1  0x0004b47a in copyAndForward (oldOop=0x162e2e50, markOnTenure=0, objShouldBeTenured=0) at src/mman/mmScavenge.c:2231

#2  0x0004ba39 in scavengeRefBlock (currentRefPtr=0x1633673c, numRefs=0, markOnTenure=0) at src/mman/mmScavenge.c:2161

#3  0x0004bb1f in scavengeFutureSpace (currentOop=0x1633672c, markOnTenure=0) at src/mman/mmScavenge.c:1377

#4  0x0004bf57 in generationScavenger (additionalTenureFunc=0x27f, attemptTheScavenge=0, scavengePurpose=758304) at src/mman/mmScavenge.c:848

#5  0x0004d19d in scavengeNewSpace () at src/mman/mmScavenge.c:405

#6  0x00060aaf in handleSyncRequests () at src/stack/services.c:294

#7  0x00063f76 in rtAbortSend ()

Previous frame inner to this frame (gdb could not unwind past this frame)

--------------------------------------------------------------------------------------------------------------------

 

but that doesn't tell me much.  Anyone have a suggestion to help me sort this out?  If it is truly a memory problem, why don't I get the usual "out of space" notifier, for example?

 

David

 

 

 

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
cdavidshaffer
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Help debugging VM crash

cdavidshaffer
<base href="x-msg://21/">
On Jan 10, 2012, at 9:52 AM, Boris Popov, DeepCove Labs wrote:

David,
 
Try starting the VM with -xq switch as per below,
 

Wow, that was very helpful, thanks!  It looks like the debugger was causing the problem (stack attached if anyone is interested in explaining).  I've enabled event faithful debugging to see if that makes a difference....still running after an hour :-)

David

<base href="x-msg://21/">
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

stack.txt (24K) Download Attachment
Andres Valloud-4
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Help debugging VM crash

Andres Valloud-4
I suspect it can't really be the debugger because from stack.txt there
are only 3 old segments and likely that did not run into the upper
memory bound.  Run the application with the headless memory monitor
loaded and check the output near the end in the resulting CSV log.  You
should be able to see what has been going on with memory before the
crash, and that should give us clues as to what's happening.

Also, did you modify the memory policy or the sizesAtStartup?

On 1/10/12 8:52 , David Shaffer wrote:

>
> On Jan 10, 2012, at 9:52 AM, Boris Popov, DeepCove Labs wrote:
>
>> David,
>> Try starting the VM with -xq switch as per below,
>
> Wow, that was very helpful, thanks! It looks like the debugger was
> causing the problem (stack attached if anyone is interested in
> explaining). I've enabled event faithful debugging to see if that makes
> a difference....still running after an hour :-)
>
> David
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
cdavidshaffer
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Help debugging VM crash

cdavidshaffer

On Jan 10, 2012, at 3:00 PM, Andres Valloud wrote:

> I suspect it can't really be the debugger because from stack.txt there
> are only 3 old segments and likely that did not run into the upper
> memory bound.  Run the application with the headless memory monitor
> loaded and check the output near the end in the resulting CSV log.  You
> should be able to see what has been going on with memory before the
> crash, and that should give us clues as to what's happening.

Very cool tool.  Looks like I filled Old space and become: on an IdentitySet was failing (don't see the connection but that's OK).  I guess the memory situation was so dire that I couldn't debug this using the normal tools...?

>
> Also, did you modify the memory policy or the sizesAtStartup?
>

No but now I'm running with -m6 100m and the app is working well.  I also plugged the leaking code.

Thanks for all the tips folks!

David

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Andres Valloud-6
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Help debugging VM crash

Andres Valloud-6
> Very cool tool.  Looks like I filled Old space and become: on an
> IdentitySet was failing (don't see the connection but that's OK).

The implementation of become: must work within constraints regarding the
location of object data for object table entries.  Sometimes it has to
copy objects around, and if it can't do that because there's not enough
space then it will delegate to the image to sort it out.  If there is
not enough space, then the become: will fail.

> No but now I'm running with -m6 100m and the app is working well.  I
> also plugged the leaking code.

Note that -m6 merely allocates old space at startup.  This also creates
a single chunk of about 100m of old space.  If you don't actually need
this change, you should consider skipping it.  Just a thought though.

Andres.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Free forum by Nabble Edit this page