March 2011 - Xquartz-dev - lists.macosforge.org

Strange Xlib error with e17
by Dave Ray 10 Mar '11

10 Mar '11

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

2 1

Re: [Xquartz-dev] libpng headers work again in XQuartz 2.6.1_rc1
by Dave Ray 09 Mar '11

09 Mar '11

On Mar 9, 2011, at 7:00 AM, Jeremy wrote: > My guess is that they are doing some '#include <png.h>' without the CPPFLAGS given to them by pkg-config, so they're getting /opt/X11/include/png.h rather than /opt/X11/include/libpng14/png.h ... but I can't really tell for certain because you've never provided any logs showing the problem. Since libpng in 2.6.1_rc1 is the same as 2.6.1_beta, I am pretty sure the problem was a config issue on my end that I missed, probably a stray file I neglected to delete. Your answer was helpful, and I didn't want to waste bandwidth debugging my config. FYI the app aggressively looked for libpng14.pc, then libpng12.pc, then libpng.pc. It ignored what version was intended to be used from sym links. It looked in every possible location for libpng14.pc first, ignoring the preferred location that appears first in PATH., LD_LIBS, etc. The app actually compiled fine until libpng15 came along. The hurdles I had to go through shouldn't have happened, and were not due to anything faulty in XQuartz. I have fed this back to the app developers. I have a much more important and difficult problem with this app that is less clear where the problem lies, and I would rather spend our cycles looking at that. I will make a separate post to keep topics organized. I will post detailed logs for that, since I'm sure it isn't a user config issue.

1 0

Re: [Xquartz-dev] libpng headers work again in XQuartz 2.6.1_rc1
by Dave Ray 08 Mar '11

08 Mar '11

On Mar 7, 2011, Jeremy wrote: > No. 2.6.1_rc1 and 2.6.1_beta1 have the exact same libpng setup. > 2.6.0 had 1.4.x ... please answer my earlier questions, and I will help you get to the bottom of it. Okay, thanks, that's all I was trying to check on. As I mentioned the problem is gone in the latest XQuartz. I no longer need to pursue this, unless you want me to look into it further. I would have to revert to an older version XQuartz and try to reproduce the problem. Just for the record here is a summary of what i observed: One app I have been trying to compile (e17 svn on a non-Fink/Macports environment) has source code that will fail if more than one version of libpng exists in either the .pc, file or headers, regardless of PATH. It aggressively looks for version-specific libpng .pc files, starting with 1.4, then 1.2, then 1.0, then "libpng". This caused it to ignore libpng1.5 if 1.4 was installed, regardless of sym links, PATH, CFLAGS etc. So I have been pruning everything libpng-related in bin, include, lib and lib/pkgconfig for the different base configs, leaving only one to be used. For XQuartz 2.6.0 and earlier, I pruned out libpng in /usr/X11, leaving only those from XQuartz in /opt/X11. This worked and no further tuning was needed. On XQuartz versions after 2.6.0 and before 2.6.1_rc1, the app that previously compiled was failing with png errors, although I thought nothing else had changed on my system. That's when I originally posted my question about what had changed. I never fully understood the reason for the errors and never resolved them. The easiest and fastest solution was to prune libpng out of /opt/X11 and install my own into /usr/local/. The errors went away for reasons I'm still not clear about. For each installation of XQuartz, I would temporarily move out all my libpng files out of /usr/local to see if the problem still existed. If so, I would move back my /usr/local files, and re-prune /opt/X11, in order to compile this app. In the 2.6.1_rc1 release, the app compiled fine against the libpng in /opt/X11 and I can permanently get rid of the libpng files in /usr/local. The problem went away for reasons I'm not clear about and I no longer need to pursue the issue. My intention was to understand the cause of the make errors so that I could feed that back to the app developers. I'm usually pretty good at identifying config issues and had checked out my system several times over without anything conclusive. Does the XQuartz installer delete libs/includes/pc files from older XQuartz distros? If not, there may have been stray or old .pc files in /opt/X11 left over from the old XQuartz distros that I failed to prune. -Dave

2 1

libpng headers work again in XQuartz 2.6.1_rc1
by Dave Ray 06 Mar '11

06 Mar '11

I posted recently about XQuartz causing compile errors related to libpng. The problem was likely not due to a problem in XQuartz, but the installation triggered a mismatch in libpng versions. I didn't have any user-installed libpng files when the errors occurred, and the cause was a mystery. My only solution was to install my own libpng into /usr/local and prune out the ones in /opt/X11. This is what I have been doing for the last few revs. Each time I installed XQuartz the problem came back until I pruned them out. I want to report that XQuartz 2.6.1_rc1 does not have this problem. I installed it and repeated my test of compiling an X11 app that requires libpng. I expected errors, and expected to prune out /opt/X11 again. But this time the apps compiled without error. Did something change in XQuartz 2.6.1_rc1 with regards to libpng? .pc files? Whatever it was, it's working now.

2 3