Bug 92875 - libXt crash introduced in XQuartz 2.7.9_beta1
Summary: libXt crash introduced in XQuartz 2.7.9_beta1
Status: RESOLVED NOTOURBUG
Alias: None
Product: XQuartz
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: development (betas, rcs, git)
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium normal
Assignee: Jeremy Huddleston Sequoia
QA Contact: Jeremy Huddleston Sequoia
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-09 21:15 UTC by FX
Modified: 2015-11-09 22:25 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description FX 2015-11-09 21:15:20 UTC
Since I installed XQuartz 2.7.9_beta1 (on my laptop runnning El Capitan), running xmgrace-5.1.25 (http://plasma-gate.weizmann.ac.il/Grace/) leads to a asan crash. This version of xmgrace was compiled for El Capitan and linked with the previous XQuartz version (I compiled it late August, with what was at the time the beta XQuartz version, i.e. 2.7.8). It ran perfectly fine with that version, but now gives an asan crash:

$ /opt/grace/grace/bin/xmgrace 
=================================================================
==16101==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000101ff6428 at pc 0x00010227c4b5 bp 0x7fff5e155c30 sp 0x7fff5e155c28
READ of size 4 at 0x000101ff6428 thread T0
   #0 0x10227c4b4 in XtGetClassExtension (libXt.6.dylib+0x7d4b4)
   #1 0x1022a6a69 in InheritObjectExtensionMethods (libXt.6.dylib+0xa7a69)
   #2 0x1022a5b88 in ObjectClassPartInitialize (libXt.6.dylib+0xa6b88)
   #3 0x1022300b6 in CallClassPartInit (libXt.6.dylib+0x310b6)
   #4 0x102230037 in CallClassPartInit (libXt.6.dylib+0x31037)
   #5 0x102230037 in CallClassPartInit (libXt.6.dylib+0x31037)
   #6 0x102230037 in CallClassPartInit (libXt.6.dylib+0x31037)
   #7 0x102230037 in CallClassPartInit (libXt.6.dylib+0x31037)
   #8 0x102230037 in CallClassPartInit (libXt.6.dylib+0x31037)
   #9 0x102230037 in CallClassPartInit (libXt.6.dylib+0x31037)
   #10 0x102230037 in CallClassPartInit (libXt.6.dylib+0x31037)
   #11 0x10222fe40 in XtInitializeWidgetClass (libXt.6.dylib+0x30e40)
   #12 0x10222fdaf in XtInitializeWidgetClass (libXt.6.dylib+0x30daf)
   #13 0x10222fdaf in XtInitializeWidgetClass (libXt.6.dylib+0x30daf)
   #14 0x102234e6d in xtWidgetAlloc (libXt.6.dylib+0x35e6d)
   #15 0x1022313cc in xtCreate (libXt.6.dylib+0x323cc)
   #16 0x102233fa6 in _XtAppCreateShell (libXt.6.dylib+0x34fa6)
   #17 0x102234176 in XtAppCreateShell (libXt.6.dylib+0x35176)
   #18 0x101b29911  (xmgrace+0x100081911)

0x000101ff6428 is located 32 bytes to the right of global variable 'vendorShellWidgetClass' defined in 'Vendor.c:136:49' (0x101ff6400) of size 8
0x000101ff6428 is located 40 bytes to the right of global variable 'vendorShellClassRec' defined in 'Vendor.c:86:54' (0x101ff62e0) of size 288
SUMMARY: AddressSanitizer: global-buffer-overflow (libXt.6.dylib+0x7d4b4) in XtGetClassExtension
Shadow bytes around the buggy address:
 0x1000203fec30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x1000203fec40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x1000203fec50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x1000203fec60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x1000203fec70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1000203fec80: f9 f9 f9 f9 f9[f9]f9 f9 00 00 00 00 00 00 00 00
 0x1000203fec90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x1000203feca0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x1000203fecb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x1000203fecc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x1000203fecd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
 Addressable:           00
 Partially addressable: 01 02 03 04 05 06 07 
 Heap left redzone:       fa
 Heap right redzone:      fb
 Freed heap region:       fd
 Stack left redzone:      f1
 Stack mid redzone:       f2
 Stack right redzone:     f3
 Stack partial redzone:   f4
 Stack after return:      f5
 Stack use after scope:   f8
 Global redzone:          f9
 Global init order:       f6
 Poisoned by user:        f7
 Container overflow:      fc
 Array cookie:            ac
 Intra object redzone:    bb
 ASan internal:           fe
 Left alloca redzone:     ca
 Right alloca redzone:    cb
==16101==ABORTING



The crash appears to come from libXt. It’s nothing specific to this version of grace, or the compiler, or the original Xquartz version it was linked with: I have old versions of xmgrace around dating back 5 years, and all crash with the same issue.

I have uploaded an tarball of the compiled xmgrace so that you may test yourself: https://www.dropbox.com/s/o4a5l5eskgmx3ia/grace-5.1.25.tar.bz2?dl=0
Run the grace/bin/xmgrace binary with no argument to get the crash.
Comment 1 Jeremy Huddleston Sequoia 2015-11-09 21:28:48 UTC
Yes, I enabled ASan in this release to help find issues.

The issue here is that there are conflicting symbols in the namespace.  The libXt part of this issue issue was fixed by rebuilding as libXt.7.dylib without -flat_namespace, but we kept libXt.6.dylib for binary compatibility reasons.  You'll need to fix grace and/or motif to use the libXt.7.dylib.

Note that ASan won't be enabled in the release candidates nor final release, so you won't see this crash report in at that time, but the bug will still be there (just as it always has been).
Comment 2 FX 2015-11-09 21:33:21 UTC
But then, you'll get people like me, otherwise happy to help test beta releases, who'll just go back to the stable ones. Breaking compatibility by default is uncool.
Comment 3 Jeremy Huddleston Sequoia 2015-11-09 21:45:58 UTC
This doesn't break compatibility.  We *explicitly* include both libXt.6.dylib (flat namespace) and libXt.7.dylib (two level namespace) so as to not break compatibility.
Comment 4 Jeremy Huddleston Sequoia 2015-11-09 21:47:03 UTC
And as far as not testing betas, that's the wrong approach.  You should fix the bug in grace and/or motif that the beta helped you uncover.  Don't just ignore it.  The bug has always been there, but you just never saw the memory corruption.
Comment 5 Jeremy Huddleston Sequoia 2015-11-09 21:49:31 UTC
Actually, it's a read overrun, so there might not be any actual corruption (unless there are other writes elsewhere, later).  However, this is ASan finding a bug in grace/motif.  It's not something that we can fix.
Comment 6 FX 2015-11-09 21:56:50 UTC
(In reply to Jeremy Huddleston Sequoia from comment #5)
> Actually, it's a read overrun, so there might not be any actual corruption
> (unless there are other writes elsewhere, later).  However, this is ASan
> finding a bug in grace/motif.  It's not something that we can fix.

I can definitely understand your point of view. I'm just pointing out that it might have the opposite effect of what you expected.

It just happens that there are exactly 3 programs I use XQuartz with, and all three crash with the new beta. All of them old programs, used by lots of people on lots of different architectures. So maybe the bugs are false positive from asan, probably (for wine) it's asan not playing nice with wine (both are doing playing tricks with the memory), maybe it's an actual bug that is latent but doesn't impact the correct working of the software.

In all three cases, I don't have time to debug all the software I run. I'm not going to debug motif or wine (even if I actually could, which is not even sure at all). Not all users (even power users) have time to. And I'm just writing to let you know, although it's anecdotal evidence so far, that 3/3 means it's probably going to be a pain in other people's bottom too.

In any case, best of luck with XQuartz, it's really useful.
Comment 7 Jeremy Huddleston Sequoia 2015-11-09 22:25:31 UTC
(In reply to FX from comment #6)
> (In reply to Jeremy Huddleston Sequoia from comment #5)
> > Actually, it's a read overrun, so there might not be any actual corruption
> > (unless there are other writes elsewhere, later).  However, this is ASan
> > finding a bug in grace/motif.  It's not something that we can fix.
> 
> I can definitely understand your point of view. I'm just pointing out that
> it might have the opposite effect of what you expected.

On the contrary, the effect was to uncover bugs that have been dormant and provide improved diagnostic logs for crashes that have been difficult to triage.

> It just happens that there are exactly 3 programs I use XQuartz with, and
> all three crash with the new beta. All of them old programs, used by lots of
> people on lots of different architectures. So maybe the bugs are false
> positive from asan, probably (for wine) it's asan not playing nice with wine
> (both are doing playing tricks with the memory), maybe it's an actual bug
> that is latent but doesn't impact the correct working of the software.

Yes, ASan is great at finding odd dormant bugs.

> In all three cases, I don't have time to debug all the software I run. I'm
> not going to debug motif or wine (even if I actually could, which is not
> even sure at all). Not all users (even power users) have time to. And I'm
> just writing to let you know, although it's anecdotal evidence so far, that
> 3/3 means it's probably going to be a pain in other people's bottom too.

yes, no doubt.  However, if you have time to file bug reports, please do so with the responsible teams (eg: wine, motif, grace).  It's not your responsibility to triage and fix them, but you should be able to spend a few minutes to report the issue to them.

> In any case, best of luck with XQuartz, it's really useful.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.