Bug 20357 - vmware workstation 6.5.1 crashes, caused by xkb changes
Summary: vmware workstation 6.5.1 crashes, caused by xkb changes
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Input/XKB (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: highest blocker
Assignee: Daniel Stone
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: have-backtrace, regression
Depends on:
Blocks: xserver-1.6.1
  Show dependency treegraph
 
Reported: 2009-02-27 09:56 UTC by Dirk Hohndel
Modified: 2010-09-20 03:08 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Dirk Hohndel 2009-02-27 09:56:10 UTC
Overview:
vmware workstation 6.5.1 crashes - sometimes right after starting, sometimes it takes some playing around with it; it usually happens within a minute or two.

Steps to reproduce:
start vmware workstation 6.5.1 (I only tried this with Windows XP client - don't know if that's a requirement to reproduce the bug)
after a short while you will get a hard crash

from the logfile:
Feb 27 09:00:13.169: mks| SymBacktrace[0] 00007f63ab127910 rip=0000000000417d2c in function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0000000000400000
Feb 27 09:00:13.169: mks| SymBacktrace[1] 00007f63ab127930 rip=00000000004defe0 in function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0000000000400000
Feb 27 09:00:13.169: mks| SymBacktrace[2] 00007f63ab127e10 rip=000000000046c598 in function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0000000000400000
Feb 27 09:00:13.169: mks| SymBacktrace[3] 00007f63ab127f00 rip=0000003b2f80f0f0 in function (null) in object /lib64/libpthread.so.0 loaded at 0000003b2f800000
Feb 27 09:00:13.169: mks| SymBacktrace[4] 00007f63ab128358 rip=0000003b2ec32f05 in function gsignal in object /lib64/libc.so.6 loaded at 0000003b2ec00000
Feb 27 09:00:13.169: mks| SymBacktrace[5] 00007f63ab128360 rip=0000003b2ec34a73 in function abort in object /lib64/libc.so.6 loaded at 0000003b2ec00000
Feb 27 09:00:13.169: mks| SymBacktrace[6] 00007f63ab128490 rip=0000003b2ec2bef9 in function __assert_fail in object /lib64/libc.so.6 loaded at 0000003b2ec00000
Feb 27 09:00:13.169: mks| SymBacktrace[7] 00007f63ab128500 rip=00007f63e57c1bc7 in function _XRead in object /opt/X11R7/lib/libX11.so.6 loaded at 00007f63e5776000
Feb 27 09:00:13.169: mks| SymBacktrace[8] 00007f63ab128520 rip=00007f63e57c1be9 in function _XReadPad in object /opt/X11R7/lib/libX11.so.6 loaded at 00007f63e5776000
Feb 27 09:00:13.169: mks| SymBacktrace[9] 00007f63ab128540 rip=00007f63e57a925d in function XGetModifierMapping in object /opt/X11R7/lib/libX11.so.6 loaded at 00007f63e5776000

I bisected the problem and got this result:
f062e90a95f9b7ae5458ef2100615e8ace9b66a7 is first bad commit
commit f062e90a95f9b7ae5458ef2100615e8ace9b66a7
Author: Daniel Stone <daniel@fooishbar.org>
Date:   Wed Apr 16 19:15:30 2008 +0300

    Input: Remove modifierKeyMap
    
    Since modifierKeyMap is generated from modifierMap, just remove it, and
    only generate it when we need to send the modifier map to the client.
    
    Signed-off-by: Daniel Stone <daniel@fooishbar.org>
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

:040000 040000 06aab23c090ed15e2f0717a268fec2a513623d82 2915098bce639e58b10c864a9e8b2718ca45c9fd M	Xi
:040000 040000 f96cdcd2fc6a7f3b7fb7ecd06bd54d826f9ae951 2101a653015ba782fbedaa529bab0690953aad9b M	dix
:040000 040000 1323147dac52590fe241d46eb3ef0cf3edb97cd7 792af8c6331f77723a35ec341ce62666dabcd838 M	hw
:040000 040000 316f07c3545508dbfc507b4dbea8527b573ce996 1f6c496ffe24bb5740e4fd254fa62a521c6624ef M	include
:040000 040000 c48224593d0cac3a70fe6135c9857f6159831abf fc3f58eb80b3314a3ff0155b39c535df93eea555 M	xkb
Comment 1 Julien Cristau 2009-03-01 16:36:13 UTC
if it was bisected to a commit that's not in 1.6, it can't be a blocker
for 1.6.1...
Comment 2 Michel Dänzer 2010-02-18 07:38:18 UTC
So it looks like Daniel's commit breaks an assumption made in XGetModifierMapping(). Peter or Daniel, do you think this is a bug in the server or Xlib/XCB?

Bug 24046 is probably about the same issue.

Haven't seen this myself with VMware Workstation nor xmodmap, so apparently there's some specific prerequisite for it to trigger - any ideas what that could be?
Comment 3 Daniel Stone 2010-02-18 10:24:57 UTC
(In reply to comment #2)
> So it looks like Daniel's commit breaks an assumption made in
> XGetModifierMapping(). Peter or Daniel, do you think this is a bug in the
> server or Xlib/XCB?
> 
> Bug 24046 is probably about the same issue.
> 
> Haven't seen this myself with VMware Workstation nor xmodmap, so apparently
> there's some specific prerequisite for it to trigger - any ideas what that
> could be?

Is this not fixed in later -- less broken -- versions of the server? I can't test myself as I don't have VMWare Workstation, and even if I did, it's kind of hard to see exactly why a binary-only app is crashing ...
Comment 4 Peter Hutterer 2010-02-18 18:14:48 UTC
(In reply to comment #2)
> So it looks like Daniel's commit breaks an assumption made in
> XGetModifierMapping(). Peter or Daniel, do you think this is a bug in the
> server or Xlib/XCB?

if it's crashing in the client (judging by the trace) but can be bisected to an X server commit it's likely that we've inadvertently broken the protocol. so my guess it is server side (what server version are we talking here anyway?)

would need at least the protocol flow to see what breaks, or some testcase that's reproducible.

> Haven't seen this myself with VMware Workstation nor xmodmap, so apparently
> there's some specific prerequisite for it to trigger - any ideas what that
> could be?

my bet is some custom modifier key setup that triggers some wrong calculation in the server (or wrong return values). how that could look like - I don't know though.
Comment 5 Michel Dänzer 2010-02-19 02:32:52 UTC
(In reply to comment #4)
> (what server version are we talking here anyway?)

AFAICT the commit in question was first released in 1.7.


> > Haven't seen this myself with VMware Workstation nor xmodmap, so apparently
> > there's some specific prerequisite for it to trigger - any ideas what that
> > could be?
> 
> my bet is some custom modifier key setup that triggers some wrong calculation
> in the server (or wrong return values). how that could look like - I don't know
> though.

Could it be related to a specific XKB configuration? Or xmodmap?


(In reply to comment #3)
> Is this not fixed in later -- less broken -- versions of the server?

I don't know - Dirk, are you still seeing this with xserver 1.7.x releases?

> I can't test myself as I don't have VMWare Workstation, and even if I did,
> it's kind of hard to see exactly why a binary-only app is crashing ...

Sure, that's where bug 24046 comes in.
Comment 6 Dirk Hohndel 2010-02-19 06:47:16 UTC
It looks like VMware worked around the issue. As of 6.5.3 (IIRC) it no longer happened. I am now running VMware Workstation 7.0.1 with X server 1.7.4 and can confirm that the problem is gone.
I looked around and can't seem to find a copy of VMware 6.5.1 anymore, so I can't go back and try to reproduce the original issue.

Don't know how to close the bug - maybe it was a VMware bug that got exposed by the change to X server behavior? Therefore NOTOURBUG. But I'm not sure this is true - it could indeed be a bug in X that VMware is just working around.

Dirk
Comment 7 Michel Dänzer 2010-02-19 07:17:18 UTC
(In reply to comment #6)
> It looks like VMware worked around the issue. As of 6.5.3 (IIRC) it no longer
> happened.

I can't seem to find any trace of an intentional workaround for this in the VMware code. Of course it's possible that some change between 6.5.1 and 6.5.3 happened to stop triggering this, but maybe you also updated the X server around the same time?


> I looked around and can't seem to find a copy of VMware 6.5.1 anymore, so I
> can't go back and try to reproduce the original issue.

Try

http://downloads.vmware.com/d/details/workstation_6_5_1_for_linux/dHdiZGQqYiV3


> Don't know how to close the bug - maybe it was a VMware bug that got exposed by
> the change to X server behavior?

Seems more likely to be an issue between the X server and Xlib/XCB.
Comment 8 Michel Dänzer 2010-09-20 03:08:37 UTC
Nobody seems able to reproduce this anymore, assuming it's fixed. If somebody can still reproduce with recent xserver and Xlib/XCB, please reopen.
Comment 9 Dirk Hohndel 2010-09-20 03:08:43 UTC
I am on sabbatical until 9/23. Upon return I will be unconditionally deleting my complete Inbox.

If you wanted to reach me personally then I take it you know my personal email address - please send your message there instead. For anything else, please send another message after 9/23.

/D


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.