Segmentation fault from "xterm" command

Question

Level 1

0 points

Segmentation fault from "xterm" command

I can't start "xterm", "xeyes" and a lot of other X11 programs. Some are installed with Apple's X11, others with fink.
A lot of other X11 commands works fine, though.

The error message is "Segmentation fault"

Server version 10.4.8

Powermac G5, Mac OS X (10.4.7), Server

Posted on Oct 2, 2006 2:41 AM

Reply

Answer 1

Oct 3, 2006 4:56 AM in response to Mikael Lund

Mikael,
I suggest that you disable fink for a while (by renaming its directory) and try to run X applications that are located inside /usr/X11R6/bin to see if your installation is working.
If yes, it may be a conflict between fink and Apple libraries.
If no, you may re-install X and try to make it work.
You can also create a new user account and check things there.

Mihalis.

Reply

Answer 2

Mikael Lund Author

Level 1

0 points

Oct 3, 2006 8:19 AM in response to Mihalis Tsoukalos

Hi,
I tried to rename /sw and also reinstalled X11. No luck.

The problem persists even for ssh clients tunelling X11, so it might not be related to the X server. And it happens for fink as well as Apple installed X11 applications. There is an xterm.crash.log but it doen't make much sense to me:

Command: xterm
Path: /usr/X11R6/bin/xterm
Parent: bash [6080]

Version: ??? (???)

PID: 6081
Thread: 0

Exception: EXC BADACCESS (0x0001)
Codes: KERN INVALIDADDRESS (0x0001) at 0x9b3aae9c

Thread 0 Crashed:
0 <<00000000>> 0x9b3aae9c 0 + -1690653028
1 libXt.6.dylib 0x9c1e7040 XtOpenDisplay + 384
2 libXt.6.dylib 0x9c1e7dc0 _XtAppInit + 224
3 libXt.6.dylib 0x9c1f18c4 XtOpenApplication + 100
4 xterm 0x0002c2d8 main + 1156
5 xterm 0x000025b0 start + 812
6 xterm 0x000022b4 start + 48

Thanks / Mikael

Reply

Answer 3

Mikael Lund Author

Level 1

0 points

Oct 3, 2006 9:42 AM in response to Mikael Lund

Now I tried this:
1) Clean install of MacOS X Server 10.4.7
2) xterm etc. works fine.
3) Software update to 10.4.8 + Quicktime/iTunes 7.
4) xterm etc. broken (segmentation fault)

No setups made, no extra installs. Pure Apple.
I suspect Quicktime is the problem...

Reply

Answer 4

Mikael Lund Author

Level 1

0 points

Oct 3, 2006 10:36 AM in response to Mikael Lund

And now this:
1) Clean install of 10.4.7 server. Again.
2) Software update -> 10.4.8
3) xterm etc. broken.

Come again, Apple.

Reply

Answer 5

kocolosk

Level 1

4 points

Oct 12, 2006 3:51 PM in response to Mikael Lund

Hi Mikael,

Just wanted to say that I have observed the same problem as you on 10.4.8. This is very annoying. It's a pretty basic QA test.

Reply

Answer 6

kocolosk

Level 1

4 points

Oct 13, 2006 5:37 AM in response to Mikael Lund

Hi, I just submitted a bug report (#4782219) to Apple for this. I'll post any response here.

Reply

Answer 7

kocolosk

Level 1

4 points

Oct 13, 2006 6:38 AM in response to Mikael Lund

Hi all,

Well, in a final act of desperation I tried replacing libXt.6.0.dylib on the (Universal) server with the version from my MacBook Pro. They were identically sized files, but for some reason (unbeknownst to me) this did the trick! Maybe this will help others experiencing this problem. Thanks,

Adam

Reply

Answer 8

Oct 13, 2006 2:12 PM in response to kocolosk

Hi Adam,
Hackers have crafted alternative executables that have the same size as the original it isn't likely that they would do it just to cause a segfault. More likely would be that they are the same file inside but have different metadata like permissions or ownership. Either of those would be fixed by running Repair Permissions in Apple's Disk Utility application.

To those of you who did it, shame on you for bad-mouthing Apple without having run Repair Permissions. A small fraction of people always have some permissions altered by installations and the running of Repair Permissions should be SOP after an install.
--
Gary
~~~~
Marriage is a great institution -- but I'm not
ready for an institution yet.
-- Mae West

Reply

Answer 9

kocolosk

Level 1

4 points

Oct 14, 2006 9:06 PM in response to Gary Kerbaugh

Hi Gary,

I'm not convinced I have any reason to be ashamed. If Repair Permissions should be SOP after an update, then Apple should run it as part of the update. After I got things working again the idea that the permissions were incorrect on the old dylib did cross my mind, but I had already removed the backup, so I can't confirm that this was the case.

Adam

Reply