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