vw7.7.1nc can't find source on Windows

>
> maybe that can point your investigation in a useful direction.
>
>
> On Tue, Aug 23, 2011 at 1:18 PM, Ross Boylan <[hidden email]>
> wrote:
>         On Tue, 2011-08-23 at 02:16 -0700, Andres Valloud wrote:
>         > Under -o11s, 100% CPU utilization is a side effect of very
>         expensive
>         > checks being performed while running the IGC in
>         interruptible mode.
>         > Basically, the length of the checks effectively ensure the
>         IGC will
>         > always be interrupted before you can do any work.  Go to the
>         memory
>         > policy and you will find something equivalent to
>         >
>         > idleLoopIGCAction
>         >
>         >       [
>         >               self igcObjects: nil interruptibly: true.
>         >               self updateMemoryStatus.
>         >               self memoryStatus incGCIsResting
>         >       ] whileFalse.
>         >       self updateNumScavengesAsOfLastGC.
>         >       ObjectMemory resetSpaceLimitsIfHigher.
>         >       (self shouldForkCompactData or: [self
>         dataNeedsCompacting])
>         >               ifTrue: [self forkCompactData].
>         >       self shrinkMemoryIfRequired
>         >
>         >
>         > (your implementation may vary since I've been cleaning up
>         that stuff).
>         > Either comment out the IGC code, or change the code so that
>         the idle
>         > loop never decides to use the IGC.
>         >
>        
>         Is all the code above IGC code, or are there parts of it that
>         should
>         stay?
>         Ross
>        
>         >
>         > On 8/23/2011 12:03 AM, Holger Kleinsorgen wrote:
>         > > Hi Ross
>         > >
>         > > try to launch the image with
>         > >
>         > > vmlinux86dbg -o10s visual.im > debug.log
>         > >
>         > > All message sends will be printed to stdout. I assume that
>         there is an
>         > > infinite recursion, which should be diagnosable by looking
>         at the output.
>         > >
>         > > If it's a headfull image, my buest guess is an infinite
>         debugger
>         > > recursion. You might want to try to add the following
>         parcel to the
>         > > image and run it on Squeeze:
>         > >
>         > > http://dl.dropbox.com/u/21555916/StartupPatch.zip
>         > >
>         > > it will create an error.log file when the windowing system
>         is not active.
>         > >
>         > > On 23.08.2011 06:33, Ross Boylan wrote:
>         > >> I started the program with vmlinux86dbg -o11s about 4.5
>         days ago. It
>         > >> continues to run, spitting out messages on the launching
>         terminal like
>         > >> checkMarksInOt: incremenal GC was conservative by xxx
>         objects.
>         > >> It uses all of one CPU, and has slowly grown to 442M.
>         > >>
>         > >> Since the process is 51M when it runs successfully on
>         lenny, and the
>         > >> image file is 37M on disk, something has likely already
>         gone very wrong.
>         > >>
>         > >> I attached the debugger to it, but I am unable to
>         reattach. When I do
>         > >> so, I get the message
>         > >> Attaching to program ...
>         > >> Cannot access memory at address xxxx
>         > >> A program is being debugged already. Kill it? (y or n)
>         > >
>         > >
>         > > _______________________________________________
>         > > 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
>        
>         _______________________________________________
>         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

> On Tue, 2011-08-23 at 02:16 -0700, Andres Valloud wrote:
>> Under -o11s, 100% CPU utilization is a side effect of very expensive
>> checks being performed while running the IGC in interruptible mode.
>> Basically, the length of the checks effectively ensure the IGC will
>> always be interrupted before you can do any work.  Go to the memory
>> policy and you will find something equivalent to
>>
>> idleLoopIGCAction
>>
>> [
>> self igcObjects: nil interruptibly: true.
>> self updateMemoryStatus.
>> self memoryStatus incGCIsResting
>> ] whileFalse.
>> self updateNumScavengesAsOfLastGC.
>> ObjectMemory resetSpaceLimitsIfHigher.
>> (self shouldForkCompactData or: [self dataNeedsCompacting])
>> ifTrue: [self forkCompactData].
>> self shrinkMemoryIfRequired
>>
>>
>> (your implementation may vary since I've been cleaning up that stuff).
>> Either comment out the IGC code, or change the code so that the idle
>> loop never decides to use the IGC.
>>
> Is all the code above IGC code, or are there parts of it that should
> stay?
> Ross
>>
>> On 8/23/2011 12:03 AM, Holger Kleinsorgen wrote:
>>> Hi Ross
>>>
>>> try to launch the image with
>>>
>>> vmlinux86dbg -o10s visual.im>  debug.log
>>>
>>> All message sends will be printed to stdout. I assume that there is an
>>> infinite recursion, which should be diagnosable by looking at the output.
>>>
>>> If it's a headfull image, my buest guess is an infinite debugger
>>> recursion. You might want to try to add the following parcel to the
>>> image and run it on Squeeze:
>>>
>>> http://dl.dropbox.com/u/21555916/StartupPatch.zip
>>>
>>> it will create an error.log file when the windowing system is not active.
>>>
>>> On 23.08.2011 06:33, Ross Boylan wrote:
>>>> I started the program with vmlinux86dbg -o11s about 4.5 days ago. It
>>>> continues to run, spitting out messages on the launching terminal like
>>>> checkMarksInOt: incremenal GC was conservative by xxx objects.
>>>> It uses all of one CPU, and has slowly grown to 442M.
>>>>
>>>> Since the process is 51M when it runs successfully on lenny, and the
>>>> image file is 37M on disk, something has likely already gone very wrong.
>>>>
>>>> I attached the debugger to it, but I am unable to reattach. When I do
>>>> so, I get the message
>>>> Attaching to program ...
>>>> Cannot access memory at address xxxx
>>>> A program is being debugged already. Kill it? (y or n)
>>>
>>>
>>> _______________________________________________
>>> 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
>
>

> On Tue, 2011-08-23 at 09:03 +0200, Holger Kleinsorgen wrote:
>> Hi Ross
>>
>> try to launch the image with
>>
>>      vmlinux86dbg -o10s visual.im>  debug.log
>>
>> All message sends will be printed to stdout. I assume that there is an
>> infinite recursion, which should be diagnosable by looking at the output.
>
> Is -o10s going to show me anything that -o11s doesn't already?
>

> 2. I left the idle loop untouched, since the code is quite a bit
> different in my image.  I think the operative part is
> MemoryPolicy>>idleLoopAction
> "Run the incremental GC until interrupted if the potential benefits
> seem to warrant the effort. This message should be sent only if the
> system has nothing better to do."
>
> self updateMemoryStatus.
> self tooManyAllocationProbes ifTrue:
> [self primeThreadedDataList ifFalse:
> [[self compactData] forkAt: Processor userInterruptPriority]].
> self idleLoopGCJustified ifTrue:
> [[ObjectMemory
> primIncrementalGCIsInterruptable: true
> objects: SmallInteger maxVal
> bytes: SmallInteger maxVal.
> self updateMemoryStatus.
> memoryStatus incrementalGCState == #resting] whileFalse.
> NumScavengesAsOfLastGC := memoryStatus numScavenges.
> ObjectMemory resetSpaceLimitsIfHigher.
> self dataNeedsCompacting ifTrue:
> [[self compactData] forkAt: Processor userInterruptPriority]]
>
> There is no idleLoopIGCAction.

> On Tue, 2011-08-23 at 23:37 -0700, Andres Valloud wrote:
>>> Even with a regular vm and no debug options, the process used 100% CPU
>>> until it was around 450M, and then CPU dropped to 0.  No windows ever
>>> opened; sometimes I'm pretty sure it eventually crashed.
>>
>> Ok, then let's use -o10s, redirect the output to a file, and see what
>> happens.
> Here is the first 1.6M of the log file, gzipped.  The log file was up to
> 78M when I stopped it, but the last 98%, as far as I can tell, is a
> repeat of the ColorValue>>scaledRed:scaledGreen:scaledBlue messages
> interspersed with
> Prim fail in src/mman/mmSubscript.c @ 802 (among other addresses).
>
> I also attach the stack trace from gdb when I broke into the process
> (when I attached to it; it was launched outside of the debugger).
>
> Ross

> Hi Ross
>
> try to launch the image with
>
>     vmlinux86dbg -o10s visual.im > debug.log
>
> All message sends will be printed to stdout. I assume that there is an
> infinite recursion, which should be diagnosable by looking at the output.
>
> If it's a headfull image, my buest guess is an infinite debugger
> recursion. You might want to try to add the following parcel to the
> image and run it on Squeeze:
>
> http://dl.dropbox.com/u/21555916/StartupPatch.zip
>
> it will create an error.log file when the windowing system is not active.

>
> On 23.08.2011 06:33, Ross Boylan wrote:
> > I started the program with vmlinux86dbg -o11s about 4.5 days ago.  It
> > continues to run, spitting out messages on the launching terminal like
> > checkMarksInOt: incremenal GC was conservative by xxx objects.
> > It uses all of one CPU, and has slowly grown to 442M.
> >
> > Since the process is 51M when it runs successfully on lenny, and the
> > image file is 37M on disk, something has likely already gone very wrong.
> >
> > I attached the debugger to it, but I am unable to reattach.  When I do
> > so, I get the message
> > Attaching to program ...
> > Cannot access memory at address xxxx
> > A program is being debugged already.  Kill it? (y or n)
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Here are the results (lowered memory to 128M and used -xq with debug

> On Sun, 2011-08-28 at 02:20 -0700, Andres Valloud wrote:
> > > I ran vmlinux86dbg without any options, but with StartupPatch.  No
> > > error.log file showed up in any directories I checked.
> > >
> > > I did at least get an error at
> > > src/mman/mmScavenge.c:2427
> > > Fatal error.
> > > Out of memory.
> > >
> > > It ran for just over 24 hours.
> >
> > Ok, use the -xq switch on the same VM and try to replicate the
> > mmScavenge problem.  When it crashes, you should get a file called
> > stack.txt.  Post it here, it should have clues as to what's happening.
> > Also, to make it crash faster, first save the image with a memory upper
> > bound of e.g.: 128mb.  To do that, go to the memory tab under the image
> > settings, then save the image, and use that image to run the test.
> >
> > Andres.
> Here are the results (lowered memory to 128M and used -xq with debug
> vm).  The program ended almost immediately, and it seems to be
> font-related.  This doesn't appear to be the same problem as before.
>
> I've also include the error.log, which I believe was produced by the
> StartupPatch mentioned earlier in this thread.