Hello all, I tried to look into a Debian bug [1] where Qt applications started to crash in recent wine-development versions.
In my opinion WTInfo returns some uninitialized stack memory in LOGCONTEXTW. Qt does not look at the return value at all and calls then WTOpen, which puts some window messages near lcMsgBase into the message queue.
Most of the time this works as a random window message is just ignored. But under some circumstances an existing wine internal window message is hit, but that message needs parameters which are not given, therefore it is crashing.
This happens when there is no device attached that is usable via wintab32.dll.
I have prepared two patches: - first avoids the copy of the uninitilized stack memory. - second makes WTOpen just succeed if there is any usable device found.
But as I have no suitable hardware I could just test the behaviour in that case. Tried to use the qemu usb-wacom-tablet, but I fear that this also relies on present hardware outside of the VM.
Also I found all testbot VMs having no wintab32.dll available at all.
Therefore I would be glad if I could receive some feedback on the patches and how I should proceed with this issue, because I do really not want to break the case where such hardware is present and working.
Also should I create a Wine bug for it.
Or should this considered a Qt bug because on most systems wintab32.dll is possibly not pressent and therefore no problem. Should a bug be opened there?
Kind regards, Bernhard
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905090
On Thu, Sep 13, 2018 at 10:13 AM Bernhard Übelacker bernhardu@mailbox.org wrote:
Hello all, I tried to look into a Debian bug [1] where Qt applications started to crash in recent wine-development versions.
In my opinion WTInfo returns some uninitialized stack memory in LOGCONTEXTW. Qt does not look at the return value at all and calls then WTOpen, which puts some window messages near lcMsgBase into the message queue.
Most of the time this works as a random window message is just ignored. But under some circumstances an existing wine internal window message is hit, but that message needs parameters which are not given, therefore it is crashing.
This happens when there is no device attached that is usable via wintab32.dll.
I have prepared two patches:
- first avoids the copy of the uninitilized stack memory.
- second makes WTOpen just succeed if there is any usable device found.
But as I have no suitable hardware I could just test the behaviour in that case. Tried to use the qemu usb-wacom-tablet, but I fear that this also relies on present hardware outside of the VM.
Also I found all testbot VMs having no wintab32.dll available at all.
Therefore I would be glad if I could receive some feedback on the patches and how I should proceed with this issue, because I do really not want to break the case where such hardware is present and working.
Also should I create a Wine bug for it.
Or should this considered a Qt bug because on most systems wintab32.dll is possibly not pressent and therefore no problem. Should a bug be opened there?
Hi Bernhard, thank you for your excellent analysis of this problem! Yes, please file a report at https://bugs.winehq.org/.
I looked at your patches and I'd like to propose a simpler solution: If the computer is not a tablet, return FALSE from X11DRV_LoadTabletInfo (see attached patch). This will make WTOpen fail, and Qt will see the error and disable its tablet support. What do you think?
-Alex
Am 20.10.2018 um 05:34 schrieb Alex Henrie:
Hi Bernhard, thank you for your excellent analysis of this problem! Yes, please file a report at https://bugs.winehq.org/.
I looked at your patches and I'd like to propose a simpler solution: If the computer is not a tablet, return FALSE from X11DRV_LoadTabletInfo (see attached patch). This will make WTOpen fail, and Qt will see the error and disable its tablet support. What do you think?
-Alex
Hello Alex, thank you for taking the time looking into the issue. I created bug #46024 for it.
With X11DRV_LoadTabletInfo returning false I am perfectly fine. I was just unsure if that is "allowed" to return false just because no usable device is found.
Kind regards, Bernhard
-
Alex Henrie -
Bernhard Übelacker