Public bug reported:

The patch debian/patches/0001-Implement-XEmbed-protocol.patch adds
XEmbed protocol support, but it has some undefined behaviour bugs on
LP64 systems like x86-64. In particular, the _XEMBED_INFO property is
defined as two CARD32 values (http://standards.freedesktop.org/xembed-
spec/xembed-spec-latest.html#id2877439), but it is cast as "long" in
some places e.g.

+    /* Add XEMBED info; this operation doesn't initiate the embedding. */
+    long data[] = { XEMBED_VERSION, XEMBED_MAPPED };
+    Q_XCB_CALL(xcb_change_property(xcb_connection(), XCB_PROP_MODE_REPLACE, 
m_window,
+                                   atom(QXcbAtom::_XEMBED_INFO),
+                                   atom(QXcbAtom::_XEMBED_INFO),
+                                   32, 2, (void *)data));

...

+        const xcb_get_property_cookie_t get_cookie =
+            xcb_get_property(xcb_connection(), 0, m_window, xEmbedInfoAtom,
+                             XCB_ATOM_ANY, 0, 3);
+
+        xcb_get_property_reply_t *reply =
+            xcb_get_property_reply(xcb_connection(), get_cookie, NULL);
+        if (reply && reply->length >= 2) {
+            const long *data = (const long *)xcb_get_property_value(reply);
+            if (data[1] & XEMBED_MAPPED)
+                Q_XCB_CALL(xcb_map_window(xcb_connection(), m_window));
+            else
+                Q_XCB_CALL(xcb_unmap_window(xcb_connection(), m_window));
+        }

I discovered this when some code I compiled with -fsanitize=address
would pop up a window for an instant before it was unmapped again -
since the reply only contains two 32-bit words (I confirmed with a
debugger than reply->length == 2 and reply->format == 32), data[1] has
undefined contents. On the sending side, it is actually sending {0, 0}
rather than the intended {0, 1}. Changing "long" to "quint32" made the
problem go away.

I don't know if this is a complete fix - there are other places where
'long' is used and I don't know enough about XCB to know whether they're
broken or not (and I'd never heard of XEmbed until a few hours ago...
I'm definitely not an expert on this stuff).

Incidentally, I also have no idea why the call to xcb_get_property
passes 3 as the length, when only 2 words are expected or examined.

I used ubuntu-bug so hopefully it will pick up all the relevant
information about my system, but just in case: I'm running 13.10 on
x86-64, and I'm building from qtbase-opensource-
src_5.0.2+dfsg1-7ubuntu11.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: libqt5gui5 5.0.2+dfsg1-7ubuntu11
ProcVersionSignature: Ubuntu 3.11.0-13.20-generic 3.11.6
Uname: Linux 3.11.0-13-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: amd64
Date: Thu Nov 14 16:13:16 2013
InstallationDate: Installed on 2011-05-25 (904 days ago)
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110426)
MarkForUpload: True
SourcePackage: qtbase-opensource-src
UpgradeStatus: Upgraded to saucy on 2013-10-25 (19 days ago)

** Affects: qtbase-opensource-src (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: amd64 apport-bug saucy

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1251262

Title:
  Qt5 windows may be randomly unmapped due to assumption sizeof(long)==4

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1251262/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to