[Xquartz-dev] Strange Xlib error with e17

[Dave Ray]

I was a latecomer in upgrading to Snow Leopard, actually did this in January. One X11 app I have been porting to Mac successfully on Leopard is not running on SL. The app developers have pondered over my logs over and over and can't figure out the source of the problem. I didn't want to post here until I was sure I had exhausted their input and was sure it isn't a config issue. 

The app is enlightenment 17 window manager ("e17"). My setup does not use MacPorts or Fink. I had success installing it on Leopard and wrote up a wiki with instructions here:

  http://trac.enlightenment.org/e/wiki/MACOSX

I have two partitions with 10.5 and 10.6 respectively, with XQuartz 2.6.1_rc1 on both. The app still compiles, installs and runs on 10.5. Same exact source code.

On SL, the app compiles and installs fine, but crashes during startup. Since it is a window manager, I test it by starting XQuartz without a wm, and then run the wm by hand from an xterm. If I want, I can run gdb on the wm from the xterm.

When I run gdb, it shows that the process that actually crashes is something in Xlib. App developers say it something faulty in Xlib on SL. I'm not convinced that's true, but wanted to post my logs here so someone could take a look. 

The app outputs its own startup messages to the console, appending the X11 startup messages. On Leopard, the app is starting up without error and working, the messages look like the following:

> startx 
...
ESTART: 0.22623 [0.05375] - ecore init
ESTART: 0.27186 [0.04563] - ecore_file init
ESTART: 0.27206 [0.00020] - more ecore
ESTART: 0.27208 [0.00001] - x connect
ESTART: 0.43704 [0.16496] - ecore_con
ESTART: 0.49660 [0.05957] - xinerama
E17 INIT: XINERAMA CHOSEN: [0], 640x480+0+0
ESTART: 0.49696 [0.00036] - randr
E_RANDR: possible CRTC: 278
E_RANDR: filling 1/1 (278)
Fillng CRTC 278 (0x8945568)
CRTC 278 apparently is in mode 290, trying to find it in the list of modes..
found CRTC 278 in mode 290
ESTART: 0.49923 [0.00227] - x hints
ESTART: 0.52435 [0.02512] - x hints done
etc...


On SL, the same startup looks like:

> startx 
...
ESTART: 0.00622 [0.00002] - ecore init
INF<88513>:ecore ecore_main.c:565 _ecore_main_loop_init() enter
INF<88513>:ecore ecore_main.c:602 _ecore_main_loop_init() leave
CRI<88513>:ecore ecore_time.c:170 _ecore_time_init() Platform does not support clock_gettime. Fallback to unix time.
INF<88513>:edje edje_util.c:60 edje_freeze() fr ++ ->1
ESTART: 0.00760 [0.00137] - ecore_file init
ESTART: 0.00763 [0.00004] - more ecore
ESTART: 0.00764 [0.00001] - x connect
Xlib:  extension "DPMS" missing on display ":0.0".
ESTART: 0.03358 [0.02594] - ecore_con
ESTART: 0.03365 [0.00007] - xinerama

Then it hangs. If I start up the app from within an xterm and run it with gdb, I get the following:

> startx
...
ESTART: 0.12905 [0.00006] - ecore init
CRI<586>:ecore ecore_time.c:170 _ecore_time_init() Platform does not support clock_gettime. Fallback to unix time.
ESTART: 0.23300 [0.10395] - ecore_file init
ESTART: 0.23363 [0.00064] - more ecore
ESTART: 0.23369 [0.00006] - x connect
Xlib:  extension "DPMS" missing on display "/tmp/launch-CCRi6v/org.macosforge.xquartz:0.0".
ESTART: 0.29543 [0.06174] - ecore_con
ESTART: 0.29611 [0.00068] - xinerama

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00000001007482bb in _X11TransWritev ()
(gdb)  bt
#0  0x00000001007482bb in _X11TransWritev ()
#1  0x0000000100740aef in _XSend ()
#2  0x0000000100735c56 in XQueryExtension ()
#3  0x000000010072b281 in XInitExtension ()
#4  0x0000000100712f1e in XextAddDisplay ()
#5  0x00000001001b0e9b in XpQueryExtension ()
#6  0x000000010015bdfc in ecore_x_window_root_list ()
#7  0x00000001000b7fba in big5hkscs_2charset ()
#8  0x00000001000b82b9 in big5hkscs_2charset ()
#9  0x0000000100002768 in dyld_stub_wait ()
#10 0x00000001000018d4 in precache ()
(gdb)  


The e17 developers are saying that _X11TransWritev () is to blame, due to a faulty Xlib. The trace shows it is invoked by ecore_x_window_root_list (). 

The app developers want e17 to be cross-platform, but they don't have Macs to test on, and non-portable code may have crept in that they aren't aware of.

Are there any unit tests I can run to get a better idea of what might resolve this?

Dave