[PATCH] Fix write to uninitialized bytes for XCB event

[Scott Kostyshak]

On Sun, Feb 23, 2020 at 03:10:37PM +0100, Enrico Forestieri wrote:
> On Sun, Feb 23, 2020 at 08:22:55AM -0500, Scott Kostyshak wrote:
> > On Wed, Feb 19, 2020 at 08:07:46PM +0100, Enrico Forestieri wrote:
> > > On Wed, Feb 19, 2020 at 01:19:54PM -0500, Scott Kostyshak wrote:
> > > > 
> > > > It seems I committed too soon. Sorry for not waiting. Both the macro
> > > > approach and Enrico's proposal are cleaner than my approach. I was
> > > > planning to pursue the macro approach in a follow-up commit.
> > > 
> > > Apparently, the macro approach was abandoned by the Qt folks.
> > > 
> > > > Regarding
> > > > C++11, don't we already use range-based for loops? Or is the question
> > > > about if we require *all* of C++11?
> > > 
> > > The latter. As shown by Pavel in the other post gcc 4.7 is lacking
> > > something. As we use xcb_selection_notify_event_t only in one place,
> > > I think defining a macro is overkill. In order to avoid many calls
> > > to calloc() (I don't know how memory fragmentation is dealt with by
> > > modern compilers), we could anyway use that idea as follows:
> > > 
> > > 	union {
> > > 		xcb_selection_notify_event_t event;
> > > 		char padding[32];
> > > 	} padded_event;
> > > 	auto & nev = padded_event.event;
> > 
> > Enrico, I propose that you commit. Thanks for the fix.
> 
> According to the followups to the post by Pavel and commit 748bb5a0,
> I think that the C++11 alignas solution is preferred. Given that you
> can check its effectiveness, I think that it is better that you
> commit it.

I tried to test but probably I'm missing something in the change that I
tested since I still get the following with Valgrind:

  ==14514== Syscall param writev(vector[...]) points to uninitialised byte(s)
  ==14514==    at 0x61F578D: __writev (writev.c:26)
  ==14514==    by 0x61F578D: writev (writev.c:24)
  ==14514==    by 0x4A83BFC: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  ==14514==    by 0x4A83FD0: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  ==14514==    by 0x4A84246: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  ==14514==    by 0x4A84ACB: xcb_flush (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  ==14514==    by 0x17C906D: lyx::frontend::GuiApplication::nativeEventFilter(QByteArray const&, void*, long*) (GuiApplication.cpp:3370)
  ==14514==    by 0x5AA4EEE: QAbstractEventDispatcher::filterNativeEvent(QByteArray const&, void*, long*) (qabstracteventdispatcher.cpp:484)
  ==14514==    by 0x9C37854: QXcbConnection::handleXcbEvent(xcb_generic_event_t*) (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.12.4)
  ==14514==    by 0x9C38829: QXcbConnection::processXcbEvents(QFlags<QEventLoop::ProcessEventsFlag>) (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.12.4)
  ==14514==    by 0x9C63286: ??? (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.12.4)
  ==14514==    by 0x633684C: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.1)
  ==14514==    by 0x6336ACF: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.1)

Attached is the patch on master that I tested.

Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Better-fix-for-ensuring-32-bit-XCB-events.diff
Type: text/x-diff
Size: 1525 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20200223/6de81f26/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20200223/6de81f26/attachment.asc>