With the rootless XFree86 distribution, you can get a kernel panic by doing the following (all my X applications are running on remote machines, and I am using Oroborus as my Xwindow server, and my machine is a FireWire PowerBook, these tidbits may or may not be important). Start up Xwindow as rootless (I've got it in the dock). Add a host (xhost + hostname), then start an X application from the terminal program (so XFree86 is not active), then while the X application is starting to display its window, switch to Xwindow by clicking on the icon in the dock. The timing may have to be just right (as the window first appears?). This will cause Xwindow to exit unexpectedly, but normally for a bad memory access. If you then try to restart Xwindow, you will get a kernel panic (it may not happen on the first try, I've had Xwindow crash on startup several times, or even limp into an oddly behaving setup before the kernel panic occurs).
I have a moderate amount of UNIX experience, and I'd be happy to help in any way I can.
Thanks for all the time and effort that has gone into XFree86 rootless mode, I use it on a daily basis.
-Miguel F. Morales
mmorales@scipp.ucsc.edu
Logged In: YES
user_id=37183
Ooh, yuck. I'll try to reproduce this when I get back to my
machine. In the meantime, here's a couple things to try.
* Try a different window manager or no window manager. If it
only dies in Oroborous, that wm is doing something different.
If it dies in any window manager or no window manager, it's a
more general bug.
* Does it only die after running xhost? Does any particular
X11 application cause the crash, or will any app do?
* If you have Apple's developer tools, try running XDarwin
with gdb so we can get a function trace. From Terminal.app:
`gdb /Applications/XDarwin.app/Contents/MacOS/XDarwin`
Inside gdb, type `run -rootless` to start XDarwin. It will
run slowly, so be patient.
If and when it crashes, you should get a gdb prompt again.
Type `thread apply all bt` and send us the output.
Logged In: YES
user_id=133579
This bug is fairly old. Does this problem still occur with XDarwin 1.0.4? Kernel panic or not, I mean does XDarwin still crash under the conditions you mention?
Logged In: YES
user_id=133579
We haven't gotten any follow up feedback on this one for 3 months and there's not much we can do with it. Closing.