[Seaside] HIGH CPU - not frozen, but s...l....o....w seaside image
Florian Minjat
florian.minjat at emn.fr
Fri Mar 23 09:20:02 UTC 2007
Stop wondering how to get the output!
It was on a console through ssl connection on a unixshell virtual
computer. The output was just lost when I closed the connection two
days before. The turn around is to use nohup and it worked well. I got
all the output I wanted the second time. And I could find where the
bug came from (InputSensor>cursorPoint on an headless image).
Florian
John M McIntosh wrote:
> I'm wondering here if it printed the diagnostic messages to your console
> log? If you are on a mac look at your console.log and system.log via the
> Console application. The printAllStacks() should have sent output to stdout
>
> "Note that if you are debugging an already running program that you have
> attached to in GDB (as opposed to launching the app from within GDB),
> stdout and stderr will not be hooked up to the Terminal (they will point
> most likely to the Console or to Project Builder's Run tab, depending
> upon how you have launched your app)."
>
> So yes perhaps output to Console?
>
>
> On Mar 22, 2007, at 1:44 AM, Florian Minjat wrote:
>
>> That's what I did each times.
>> But the first time, with the frozen image without nohup, I didn't get
>> anything with gdb more than this :
>> (gdb) call printAllStacks()
>> $1 = 2
>> (gdb) call printCallStack()
>> $2 = -1551081468
>> With no output.
>> I tried with the advice of Adrian to redirect stdout and stderr inside
>> gdb (http://developer.apple.com/technotes/tn/tn2032.html), but with no
>> success.
>>
>> So I killed it and relauched with nohup, and when it froze again I got
>> the output I wanted in the nohup.out file.
>>
>> But the problem is : why did the headless image froze when it got a
>> call to InputSensor>cursorPoint ? There should be a safety in this
>> method to answer 0 at 0 when the image is headless for example.
>> Another problem is that is worked a little (50-70 calls to
>> InputSensor>cursorPoint) and then the image was to slow (100% cpu) to
>> do it. So this behavior could be triggered somewhere else in the image
>> and is annoying to debug...
>>
>> Florian
>
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
More information about the seaside
mailing list