XDarwin - look at it funny and its gone!
 

I am starting to use Xdarwin more freq. and I have noticed that it is very finicky. If you look at it the wrong way - POOF!!! It will just disappear! No error, no nothing. I may not even be on the machine, machine may be completely idle - and I come back and its XDarwin is gone. Matter of fact - I can almost always reproduce the crash by letting the screensaver invoke with XDarwin active. BOOM! XDarwin gone!

I know that its extremely hard to identify XDarwin problems - but I was hoping that maybe someone might have a clue or hint for some thing(s) I might look for as problem-causing.

Here is the most recent crash report - if it helps:

G4/400 (AGP) 1.2G RAM, using latest XDarwin, updated Fink install, etc.

Date/Time: 2002-11-07 19:08:20 -0500
OS Version: 10.2.1 (Build 6D52)
Host: <elided>

Command: XDarwin
PID: 13237

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xb2287fce

Thread 0 Crashed:
#0 0x91eca5ac in enumerate_gx_glyph_path
#1 0x91eca450 in get_glyph_data
#2 0x91eca248 in ats_get_glyph_paths
#3 0x91ec3508 in build_glyph_entries
#4 0x91ec935c in ats_glyph_get_cached_glyphs
#5 0x91ec30e4 in ats_get_8bit_quantized_bitmaps
#6 0x91ecae5c in ats_get_glyph_bitmaps
#7 0x91f549a0 in ripc_RenderGlyph
#8 0x9371e8cc in drawGlyphs
#9 0x9370f778 in CGContextShowGlyphsWithDeviceAdvances
#10 0x93720078 in CGContextShowGlyphsWithAdvances
#11 0x91a5ab58 in RenderCGGlyphs
#12 0x91a6d404 in RenderGlyphRecordArrayWithCG
#13 0x91a6d6c8 in ATSUDrawGlyphs(ATSGlyphVector*, unsigned long, unsigned long, FixedPoint*, Rect*, CGContext*)
#14 0x91a65e08 in TTextLineLayout::DrawText(unsigned long, unsigned long, long, long)
#15 0x91a65bd0 in ATSUDrawText
#16 0x92bb3c00 in TATSUTextLayout::DrawToContext(CGRect const&, unsigned char, short, short, float, CGContext*)
#17 0x92bc0b4c in TThemeText::DrawThemeTruncatedText(float, float, CGRect const&, unsigned long, short, short, float, short, OpaqueGrafPtr*, unsigned char, CGContext*, CGRect*)
#18 0x92bbf720 in DataEngine::DrawThemeTruncatedText(__CFString const*, unsigned short, TThemeDrawState const&, CGRect const&, short, short, float, short, OpaqueGrafPtr*, unsigned char, CGContext*, OpaqueThemeTextCache*, CGRect*)
#19 0x92bbf420 in _DrawThemeTruncatedTextWithCache
#20 0x92bd310c in DrawTextMenuTitle(StdMBDFGlobals*, OpaqueMenuRef*, Rect const*, __CFString const*, unsigned long, void*)
#21 0x92bde0c4 in DrawMenuTitleProc(Rect const*, short, unsigned char, long, void*)
#22 0x92be769c in DrawMenuTitleLoop(short, short, GDevice**, long)
#23 0x92bc52bc in DataEngine::DrawThemeMenuTitle(CGRect const&, CGRect const&, unsigned short, unsigned long, MenuTitleDrawingXUPP*, unsigned long, CGContext*)
#24 0x92c02008 in HIThemeDrawMenuTitle
#25 0x92be98b8 in DrawThemeMenuTitleWithContext
#26 0x92bdf184 in DrawCommon(StdMBDFGlobals*, Rect*, OpaqueMenuRef*, unsigned char, void*)
#27 0x92bd8c50 in DrawIndexedMenuTitle(StdMBDFGlobals*, int, void*, unsigned char)
#28 0x92bd8030 in DrawBar(StdMBDFGlobals*)
#29 0x92ba6418 in StandardMBDF(short, short, long, long)
#30 0x92c575d8 in MBarDraw(unsigned char, MenuData*, CGContext*)
#31 0x92c0989c in DrawMenuBarWithContext(CGContext**)
#32 0x92c66c94 in DrawMenuBar
#33 0x92c1dd38 in BroadcastInternal(unsigned long, void*)
#34 0x92c5bc08 in CFNotificationProc(__CFNotificationCenter*, void*, __CFString const*, void const*, __CFDictionary const*)
#35 0x90168b3c in _postNotification
#36 0x90166238 in _CFNotificationCenterPostLocalNotification
#37 0x901737a8 in _localPortCallBack
#38 0x9015c3e4 in __CFMachPortPerform
#39 0x9015c250 in __CFRunLoopDoSource1
#40 0x90149354 in __CFRunLoopRun
#41 0x9018157c in CFRunLoopRunSpecific
#42 0x92ba34cc in RunCurrentEventLoopInMode
#43 0x92bb32f4 in ReceiveNextEventCommon
#44 0x92bda280 in BlockUntilNextEventMatchingListInMode
#45 0x93082184 in _DPSNextEvent
#46 0x930ccf84 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
#47 0x930ca500 in -[NSApplication run]
#48 0x930d2598 in NSApplicationMain
#49 0x00002fcc in DarwinHandleGUI
#50 0x00007e60 in main
#51 0x00002be8 in _start (crt.c:267)
#52 0x00002a68 in start

Thread 1:
#0 0x90074328 in mach_msg_trap
#1 0x90006770 in mach_msg
#2 0xc00076cc in __ape_internal
#3 0xc0000dd0 in __ape_agent
#4 0x90021428 in _pthread_body

Thread 2:
#0 0x90025e8c in select
#1 0x0005fe74 in WaitForSomething
#2 0x00028944 in Dispatch
#3 0x00008504 in main
#4 0x00007538 in -[Xserver run]
#5 0x9081cd38 in forkThreadForFunction
#6 0x90021428 in _pthread_body

PPC Thread State:
srr0: 0x91eca5ac srr1: 0x0000f030 vrsave: 0x00000000
xer: 0x00000000 lr: 0x91eca570 ctr: 0x90013c00 mq: 0x00000000
r0: 0x91eca570 r1: 0xbfffc780 r2: 0xa0007530 r3: 0x000003e8
r4: 0x00000000 r5: 0x00000096 r6: 0x00000000 r7: 0x00000000
r8: 0x00000000 r9: 0x00000000 r10: 0x00000000 r11: 0x00000000
r12: 0x90013c00 r13: 0x02231e70 r14: 0x005a6ce0 r15: 0xbfffce90
r16: 0xbfffce80 r17: 0xbfffce40 r18: 0xbfffcbf0 r19: 0xa1eba284
r20: 0x0000ffff r21: 0x005776a0 r22: 0x00000000 r23: 0x00000000
r24: 0x77f0940f r25: 0xa40d6d46 r26: 0xb2287fce r27: 0x70d8940f
r28: 0x00000000 r29: 0x00006ae4 r30: 0xbfffca30 r31: 0x91eca51c

Re: XDarwin - look at it funny and its gone!
 

Uh looks like a null pointer was referenced, although I only looked at that for about 2 seconds....

That should be reported to the XonX site, http://sourceforge.net/projects/xonx since the error occurs in xdarwin specific code....

Bluehz,

Is this the same machine where you just upgraded Fink for 10.2 ?

It crashes when you are in rootless-mode ?

Can you start X11 from terminal.app with:

startx -- -rootless

And post the messages that come up, also from console.


Cheers...

Yes - same machine, but this has been a longterm happening. I just started using Xdarwin more often lately. Matter of fact I posted onthis same problem several months back on various forums and got no conclusive answers.

I always run rootless - normally start from double-clickable XDarwin.app. Note I have a very minimal .xinitrc since most of what I want XDarwin for is manipulating a headless Linux machine - all I realy need are apps not Desktops. So my .xinitrc basically fires up a coupla of xterms and a minimal blackbox wm.

Here is output requested:

% startx -- -rootless

2002-11-07 23:20:19.352 XDarwin[24610]
XDarwin 1.1.0.1
Running rootless inside Mac OS X window server.

This is a pre-release version of XFree86, and is not supported in any
way. Bugs may be reported to XFree86@XFree86.Org and patches submitted
to fixes@XFree86.Org. Before reporting bugs in pre-release versions,
please check the latest version in the XFree86 CVS repository
(http://www.XFree86.Org/cvs)

XFree86 Version 4.2.0.1 / X Window System
(protocol Version 11, revision 0, vendor release 6600)
Release Date: 21 August 2002
If the server is older than 6-12 months, or if your hardware is
newer than the above date, look for a newer version before
reporting problems. (See http://www.XFree86.Org/FAQ)
Operating System: Darwin
Using keymapping provided in /System/Library/Keyboards/USA.keymapping.
Display mode: Rootless Quartz
Screen 0 added: 1152x849 @ (0,21)
Screen 0 placed at X11 coordinate (0,0).
cat: /Users/cposey/.Xauthority: No such file or directory
BScreen::BScreen: managing screen 0 using visual 0x22, depth 24

I thought I was having some better luck when running XDarwin from terminal - e.g. startx -- -quartz --rootless. I was wrong. Disappeared 3 times this morning already. Heres latest console output. It seems to happen most freq when it is in the background. AS long as I am working on something in Xwin environ it seems to be fine - as soon as I switch over tha a Mac app for a sec - thats when I run the risk of losing it.

XFree86 Version 4.2.0.1 / X Window System
(protocol Version 11, revision 0, vendor release 6600)
Release Date: 21 August 2002
If the server is older than 6-12 months, or if your hardware is
newer than the above date, look for a newer version before
reporting problems. (See http://www.XFree86.Org/FAQ)
Operating System: Darwin
Using keymapping provided in /System/Library/Keyboards/USA.keymapping.
_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
Display mode: Rootless Quartz
Screen 0 added: 1152x849 @ (0,21)
Screen 0 placed at X11 coordinate (0,0).
cat: /Users/cposey/.Xauthority: No such file or directory
BScreen::BScreen: managing screen 0 using visual 0x22, depth 24
kCGErrorFailure : OFAGetGlyphData failed: error 268435471.
kCGErrorFailure : OFARegisterStrike failed: error 71.
kCGErrorFailure : OFARegisterStrike failed: error 268435471.
kCGErrorFailure : OFARegisterStrike failed: error 71.
kCGErrorFailure : OFAGetGlyphData failed: error 268435471.
X connection to :0.0 broken (explicit kill or server shutdown).
xterm: fatal IO error 32 (Broken pipe) or KillClient on X server ":0.0"
xterm: fatal IO error 32 (Broken pipe) or KillClient on X server ":0.0"
xinit: connection to X server lost.

This is ridiculous - I have had about 5 XDarwin crashes this morning alone. Whenever I switch into OS X to do something it disappears. Basically it is unusable!!!!

Always leaves with and error of this type:

kCGErrorFailure :

Anyone?

hmm, i smell coregraphics font problems. are all the crash log entries fundamentally the same? ...

and, is the rest of the system vanilla? can you shift-login (login, hold down shift, no user startup dealies) and get stable?

damn near every crash login always starts with:

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xb2287fce

Its been that way for a long time. FYI - clean install of 10.2.1. By no means a "clean system"......hahahaha...you mean there are actually people who use X "clean"...maybe one day when Apple builds in the basics....sorry for the rant. Yeah I wish it was vanilla - unfortunately IMHO X is unusable straight out of the box...in saying that though - I have used X from day 1 of release. Can't remember the last time I loaded classic.

I just get so infuriated with XDarwin - I find something I would like to use in XDarwin, get it all installed and working properly then can't use it. SOP! I try it while, find it unusable and give up on it. come back to it a coupla months later in hopes maybe it will work now.....hasn't been reliable enough yet to use for anything.

Funny thing is - I also have an iBook2001 that dual boots OSX/Yellow Dog Linux running KDE - and when running YDL/KDE - it is ROCK SOLID! Make me sad that my Apple issue system can't be as stable.

please login with the shift key pressed, test Xdarwin and report your results.

you don't happen to have unsanity's APE installed, do you?

Bluehz,

When it crashes, what was your Xfree86 set-up. What window manager, etc...

Making a google search with "kCGErrorFailure: ..." brings several MacOS X font, display, awaking from sleep problems. Also, when trying to run an Aqua application without the OS X window server.

I agree with MervTormel, this looks more and more a like a problem with Fonts somewhere.


Cheers...

I did not restart yet - but I did create a fresh new user to test with. Logged in with new user and getting no where with XDarwin fast...

FYI - I made sure the paths were correct, etc as usual new install of XDarwin per users...

And yes - unfortunately I do have APE installed. As far as fonts - I don't really have any thing but the stock 10.2.1 fonts installed. I use Suitcase whenever I need fonts - but I do not keep it open all teh time. The generic OS X fonts folders are untouched by me....unless the have become corrupted, etc by some process.

Xfree setup is very basic - blackbox-rootless, not any window candy, etc. Usually running one app inside it....

% startx -- -rootless

2002-11-08 13:08:02.638 XDarwin[7608]
XDarwin 1.1.0.1
Running rootless inside Mac OS X window server.

Fatal server error:
Could not create server lock file: /tmp/.X0-lock

OsVendorFatalError
AbortDDX
Quitting XDarwin...
^Cgiving up.
xinit: No such file or directory (errno 2): unable to connect to X server
xinit: No such process (errno 3): Server error

Bluehz,

What says your ~/.xinitrc file?


Cheers...

Very basic/stock .xinitrc. I also tried copying that to the test users dir thinking that might be teh problem. But it wasn't.

I also scoured my font folder - found two non-stock fonts that I removed as well as a few stock fonts that I never use.

#!/bin/sh
# $Xorg: xinitrc.cpp,v 1.3 2000/08/17 19:54:30 cpqbld Exp $

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/usr/X11R6/lib/X11/xinit/.Xresources
sysmodmap=/usr/X11R6/lib/X11/xinit/.Xmodmap

# merge in defaults and keymaps

if [ -f $sysresources ]; then
xrdb -merge $sysresources
fi

if [ -f $sysmodmap ]; then
xmodmap $sysmodmap
fi

if [ -f $userresources ]; then
xrdb -merge $userresources
fi

if [ -f $usermodmap ]; then
xmodmap $usermodmap
fi

# start some nice programs
source /sw/bin/init.sh
/sw/bin/blackbox &
xterm -geometry 80x35+494+51 &
xterm -geometry 80x20+494-0

Don't know if this makes any difference - but I restarted holding down SHIFT and have been running this afternoon basically vanilla.

Watching the Console - this is scrolling by continuously:

2002-11-08 23:13:38.456 SystemUIServer[441] Error from GetNextProcess Loop: -600

2002-11-08 23:13:38.457 SystemUIServer[441] Error from FSpMakeFSRef: -35

2002-11-08 23:13:38.458 SystemUIServer[441] [self ensureQD_XRunning]: -10814

i have to suspect APE.

Bluehz,

Do me a favor, try the following, the one you posted above is the ~/.xinitrc file in your home directory, right?

If yes, delete it.

Then, write with pico a new ~/.xinitrc file, with only the following in it and in the same order:

The last command of your .xinitrc must not be run in the background and it should be a long-living program. Customarily, the window manager is used for this purpose.

Also, if you have ~/.Xresources and ~/.Xmodmap files in your home directory, move them out of the way.

Then, start from terminal.app with the command:

startx -- -rootless

Don't use the -quartz option.

Let me know how it went.


Cheers...

I'll give that a try

So far running vanilla system - I'm having pretty good luck. No X11 crashes yet...but I haven't been stressing it.

Bluehz,

After you tried what I suggested in my last post, I have another idea, which would be to pipe the whole X session to a log file for a later autopsy. From console do a :

"startx |& tee ~/startx.log"

and log in.

Then, when you check that log file, you might be able to see something that explains where the problem is coming from. You could check the file when you log out and even from an xterm while X is running.


Cheers...

After doing some serious disabling of OS X extras - including the APE system, I am having much better luck. Been working via remote link to my Linux box via X11 using Kate and tkabber all morning with nary a problem. Also left XDarwin running all night, screensaver and all - and when i got up this morning I was amazed to fin d it still active! I am happy camper - although lets give ita day or two before we proclaim victory.

I do miss my FruitMenu though, I know, I know we should all get away from the Apple menu and any most cases I do everything via cmm MaxMenus and it works great. But after 15+ years using a Mac - every once and a while I rever back to the ol' Apple menu techiques.

hmm, so i wonder if you were to only re-enble APE, would your problems return.

unusanity's products used to work without APE.

moki (ambrosia el presidente) indicated that the APE implementation as a framework might lead to these mysterious problems that are opaque. i.e., not many clues pointed to APE.

anyhow, the real problem remains opaque and elusive.

Bluehz,

That's great news. Let us know how it goes.


mervTormel,

As always, great diagnosis.


Cheers...

Well I have had Xfree86 up and runnig all weekend with only one crash. And I think that was app related. Anyway - it appears that the APE is definitely the problem. Thanks goes out to both Merv and Sao for great patience and expertise. I thank you both!

Now I am full of questions about general Xfree86 usage. It a little off topic for this thread so I started a new thread - I hope you guys can offer some input:

http://forums.macosxhints.com/showth...&threadid=7059

- thx