[Xquartz-dev] Strange Xlib error with e17

Jeremy Huddleston jeremyhu at apple.com
Wed Mar 9 16:50:57 PST 2011


Can you please provide a crash log for this crash (usually stored in ~/Library/Logs/DiagnosticReports)

Since it runs fine on Leopard, my guess is that your application is pulling in multiple copies of Xlib which are conflicting (one from /usr/X11/lib and the other from /usr/X11/lib).  Try running it with DYLD_PRINT_LIBRARIES=1 in the environment and checking if you see libraries coming in from both /usr/X11 and /opt/X11

--Jeremy


On Mar 9, 2011, at 11:58, Dave Ray wrote:

> 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
> 
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
> 



More information about the Xquartz-dev mailing list