Hi George I've tried this both with my user, running standard apps or me.Safari, Neooffice, R, Mail etc, and with a new user, with no startups and no apps running at all. I can open no apps, or many apps in any order and the behavior is still the same. If I open X11, and then focus on something else (e.g. writing this email) the cpu goes to 100 for X11.bin - with or without the pasteboard sync checked no difference there either. I'm pasting in a sample below. Ken On Feb 8, 2009, at 1:15 PM, George Peter Staplin wrote:

Quoted Ken Nussear <knussear@mac.com>:

...

I'm using xquartz 2.3.2.1 on osx 10.5.6 on a 2.16 GHz intel core 2 duo. When x11 is running, but is not focused it begins to use 100% of my cpu until re-focused.

Repeatable 100% of the time on my machine.

I posted as Ticket #241

Can anyone help me diagnose the issue?

Ken

I think it's probably the pasteboard, but it could be something in quartz-wm. I think those are the 2 areas that deal with active/ inactive messages.

Thus far I haven't been able to duplicate the CPU load problem. These days I mostly use XQuartz for GLX testing, and testing changes to XQuartz. I don't run XQuartz for a long period of time, and it would probably help to do so again, with more apps.

What apps do you have running when it occurs?

Is there a certain pattern you have to start the apps in?

Does it always happen with the same set of apps running?

Does disabling the Pasteboard proxying affect the problem at all, or toggling it, while the cycle causing the CPU load occurs?

Are you using xclipboard, or Klipper? Do you have anything starting automatically via the startup scripts?

It might help to get a sample of the X11.bin.

George -- http://people.freedesktop.org/~gstaplin/

Sampling process 366 for 3 seconds with 1 millisecond of run time between samples Sampling completed, processing symbols... Analysis of sampling X11.bin (pid 366) every 1 millisecond Call graph: 1955 Thread_2503 1955 start 1955 main 1955 mach_msg_server 1955 mach_startup_server 1955 _Xstart_x11_server 1955 do_start_x11_server 1955 server_main 1955 X11ApplicationMain 1955 -[NSApplication run] 1955 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 1955 _DPSNextEvent 1955 BlockUntilNextEventMatchingListInMode 1955 ReceiveNextEventCommon 1955 RunCurrentEventLoopInMode 1955 CFRunLoopRunInMode 1955 CFRunLoopRunSpecific 1933 mach_msg 1933 mach_msg_trap 1933 mach_msg_trap 20 0xffffffff 20 _sigtramp 20 _sigtramp 1 __CFMachPortPerform 1 PullEventsFromWindowServerOnConnection(unsigned int, unsigned char) 1 CGEventCreateNextEvent 1 CGSGetNextEventRecordInternal 1 snarfEvents 1 _CGSGetPortStreamInline 1 mach_msg 1 mach_msg_trap 1 mach_msg_trap 1 __CFRunLoopDoObservers 1 _handleWindowsNeedUpdateNote 1 -[NSApplication updateWindows] 1 -[NSNotificationCenter postNotificationName:object:] 1 -[NSNotificationCenter postNotificationName:object:userInfo:] 1 + [NSConcreteNotification newTempNotificationWithName:object:userInfo:] 1 -[NSObject retain] 1 __CFDoExternRefOperation 1 CFBagAddValue 1 CFBagAddValue 1955 Thread_2603 1955 thread_start 1955 _pthread_start 1955 CAPThread::Entry(CAPThread*) 1955 HALRunLoop::OwnThread(void*) 1955 CFRunLoopRunInMode 1955 CFRunLoopRunSpecific 1955 mach_msg 1955 mach_msg_trap 1955 mach_msg_trap 1955 Thread_2703 1955 thread_start 1955 _pthread_start 1955 server_thread 1955 dix_main 1955 Dispatch 1628 select$DARWIN_EXTSN 1628 select$DARWIN_EXTSN 320 WaitForSomething 182 BlockHandler 146 QuartzBlockHandler 83 NSPopAutoreleasePool 43 NSPopAutoreleasePool 9 objc_assign_strongCast 9 objc_assign_strongCast 8 objc_msgSend 8 objc_msgSend 7 NSClassFromObject 4 NSClassFromObject 3 object_getClass 3 object_getClass 6 _CFExecutableLinkedOnOrAfter 6 _CFExecutableLinkedOnOrAfter 5 objc_collecting_enabled 5 objc_collecting_enabled 2 object_getClass 2 object_getClass 1 +[NSObject self] 1 +[NSObject self] 1 dyld_stub_objc_msgSend 1 dyld_stub_objc_msgSend 1 pthread_getspecific 1 pthread_getspecific 25 -[NSAutoreleasePool init] 22 -[NSAutoreleasePool initWithCapacity:] 9 -[NSAutoreleasePool initWithCapacity:] 7 NSPushAutoreleasePool 7 NSPushAutoreleasePool 2 NSClassFromObject 2 NSClassFromObject 1 -[NSObject class] 1 -[NSObject class] 1 dyld_stub_objc_msgSend 1 dyld_stub_objc_msgSend 1 objc_collecting_enabled 1 objc_collecting_enabled 1 pthread_getspecific 1 pthread_getspecific 1 dyld_stub_pthread_getspecific 1 dyld_stub_pthread_getspecific 1 objc_collecting_enabled 1 objc_collecting_enabled 1 objc_msgSend 1 objc_msgSend 12 +[NSObject alloc] 6 +[NSObject alloc] 3 +[NSAutoreleasePool allocWithZone:] 1 +[NSObject self] 1 +[NSObject self] 1 objc_assign_strongCast 1 objc_assign_strongCast 1 pthread_getspecific 1 pthread_getspecific 2 objc_msgSend 2 objc_msgSend 1 dyld_stub_pthread_getspecific 1 dyld_stub_pthread_getspecific 9 objc_msgSend 9 objc_msgSend 7 objc_collecting_enabled 7 objc_collecting_enabled 6 QuartzBlockHandler 2 -[NSAutoreleasePool release] 2 -[NSAutoreleasePool release] 1 dyld_stub_objc_collecting_enabled 1 dyld_stub_objc_collecting_enabled 1 pthread_getspecific 1 pthread_getspecific 17 objc_msgSend 17 objc_msgSend 11 AnimCurScreenBlockHandler 6 AnimCurScreenBlockHandler 5 miSpriteBlockHandler 4 miSpriteBlockHandler 1 NoopDDA 1 NoopDDA 4 BlockHandler 2 RootlessBlockHandler 2 RootlessBlockHandler 2 dyld_stub_objc_msgSend 2 dyld_stub_objc_msgSend 57 WaitForSomething 44 GetTimeInMillis 35 gettimeofday 31 __gettimeofday 18 __gettimeofday 13 __nanotime 13 __nanotime 4 gettimeofday 6 __gettimeofday 6 __gettimeofday 2 GetTimeInMillis 1 __commpage_gettimeofday 1 __commpage_gettimeofday 9 __bzero 9 __bzero 9 select$UNIX2003 9 select$UNIX2003 7 WakeupHandler 4 WakeupHandler 2 NoopDDA 2 NoopDDA 1 QuartzWakeupHandler 1 QuartzWakeupHandler 6 __error 6 __error 5 select$DARWIN_EXTSN 5 select$DARWIN_EXTSN 1 dyld_stub_gettimeofday 1 dyld_stub_gettimeofday 7 Dispatch 1955 Thread_2803 1955 thread_start 1955 _pthread_start 1955 xpbproxy_x_thread 1955 xpbproxy_input_loop 1955 pthread_cond_wait$UNIX2003 1955 __semwait_signal 1955 __semwait_signal 1955 Thread_2903 1955 thread_start 1955 _pthread_start 1955 glvmDoWork 1955 pthread_cond_wait$UNIX2003 1955 __semwait_signal 1955 __semwait_signal 1955 Thread_2a03 1955 thread_start 1955 _pthread_start 1955 DarwinProcessFDAdditionQueue_thread 1955 pthread_cond_wait$UNIX2003 1955 __semwait_signal 1955 __semwait_signal 1955 Thread_2b03 1955 thread_start 1955 _pthread_start 1955 select$DARWIN_EXTSN 1955 select$DARWIN_EXTSN 1955 Thread_2c03 1955 thread_start 1955 _pthread_start 1955 _xp_async_thread 1955 _xp_async_dequeue 1955 pthread_cond_wait$UNIX2003 1955 __semwait_signal 1955 __semwait_signal Total number in stack (recursive counted multiple, when >=5): 7 _pthread_start 7 thread_start 5 objc_msgSend Sort by top of stack, same collapsed (when >= 5): __semwait_signal 7820 mach_msg_trap 3889 select$DARWIN_EXTSN 3588 WaitForSomething 57 NSPopAutoreleasePool 43 objc_msgSend 37 __gettimeofday 24 _sigtramp 20 objc_collecting_enabled 14 __nanotime 13 objc_assign_strongCast 10 -[NSAutoreleasePool initWithCapacity:] 9 __bzero 9 select$UNIX2003 9 Dispatch 7 NSPushAutoreleasePool 7 +[NSObject alloc] 6 AnimCurScreenBlockHandler 6 NSClassFromObject 6 QuartzBlockHandler 6 _CFExecutableLinkedOnOrAfter 6 __error 6 object_getClass 5 Sample analysis of process 366 written to file /dev/stdout

I started a bare xterm as suggested and worked for a couple hours with the osx apps, occasionally using that xterm as well. Everything was cool. Literally. The CPU temperature remained in the lower forties (C), and the fan didn't come on even momentarily. Then I started icewm and gimp, and spent about 10 minutes abusing the latter. I know how to break it simply by drawing lines with a stylus. But that's a different story, I just want to comment that breaking gimp under icewm appeared to be somewhat more difficult that under quartzwm. It tends to break when it draws a continuous line too quickly and for too long -- to the point that the undo operation doesn't completely erased the line; it only erases random rectangular panels, leaving other panels unerased. Then, after 10 minutes, I noticed the 100% load by X11. Killing icewm brought it back to idle, and there it stayed for maybe another hour of gimp abuse, and everything was cool. I must also mention that without any wm, gimp worked even smoother. Then I started icewm again to rearrange the windows, and killed it again as soon as the windows were in the right pusitions. The load went up to 100% again and never came back to idle. Killing gimp didn't bring it back to idle either. So it remained at 100% with the sole xterm running. Killing X11 was enough to cool it down, but starting it again with a single xterm and no wm brought it back to 100%. So this sort of confirms the report that it is possible to have the hot idle effect with a sole xterm and no wm. I havenr't obesrved it long enough to know if it would ever arise without more sophisticated, albeit transient, use of X11; and I don't know enough to say whether wm has anything to do with that (it is hard to use anything more complicated than xterm without a window manager). All I can see is that once the situation arises, it tends to persist. I have just restarted the system, and it's again running with a single undecorated xterm, with X11 being essentially idle, wether or not I do anything in that xterm or in other apps. Now, please pardon my ignorance -- I am years of reading away from understanding any of the X11, wm or osx GUI stuff, but is there such a thing as event queue? If there is such a thing, or perhaps several, given what a nice hack XQuartz is, can it (they) be clogged with something unexpected? I am imagining something that gets inserted into the queue, then gets "read", whatever that means, but not cleaned up? Or even not read? Or, can an empty queue look non-empty? Just a WAG trying to explain why the effect is intermittent, why it is so drastic, as well as why it tends to persist even after whatever "thing" responsible for it is gone, and even after X11 is restarted. Regards, --Gene On Mon, Feb 9, 2009 at 2:51 AM, Jeremy Huddleston <jeremyhu@apple.com> wrote:

Someone reported this without quartz-wm running (.xinitrc was just 'exec xterm').

Ken, could you please make your ~/.xinitrc just contain this line: exec /usr/X11/bin/xterm

Then relaunch X11.app? You should get an undecorated xterm window. Can you see the 100% CPU usage in this scenario?