Bug 969446 - Fedora19:Beta - vnc crashes with "Pane is dead"
Fedora19:Beta - vnc crashes with "Pane is dead"
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: tigervnc (Show other bugs)
19
ppc64 All
unspecified Severity urgent
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-31 08:42 EDT by IBM Bug Proxy
Modified: 2013-10-10 10:08 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-10 10:08:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
logs from /tmp (8.53 MB, application/x-gzip)
2013-05-31 08:42 EDT, IBM Bug Proxy
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 94250 None None None Never

  None (edit)
Description IBM Bug Proxy 2013-05-31 08:42:30 EDT
== Comment: #0 - IRANNA D. ANKAD <iranna.ankad@in.ibm.com> - 2013-05-30 05:53:43 ==
I am trying vnc installation of fedora19 beta, once installer starts vnc server, I try connecting using vncviewer, after few seconds the vnc crashes with a message "Pane is dead".

This issue consistently occurs with below different vnc (tried from my RHEL6.3 desktop): Tigervnc, vinagre & gvncviewer.
I notice this vnc crash even with xtightvncviewer (from windows box), though it is intermittent there.

This issue is sort of blocking my further vnc installation.

FYI, I found below segfault & backtrace in /tmp/vncserver.log

Thu May 30 08:07:57 2013
 VNCSConnST:  Client pixel format depth 24 (32bpp) little-endian rgb888
(EE)
(EE) Backtrace:
(EE) 0: Xvnc (xorg_backtrace+0xfff4adb8) [0x102267e8]
(EE) 1: Xvnc (0x10000000+0x22b7dc) [0x1022b7dc]
(EE) 2: (vdso) (__kernel_sigtramp_rt64+0x0) [0x3fff9fb80448]
(EE) 3: Xvnc (GetEventMask+0xffef51d0) [0x101cd990]
(EE) 4: Xvnc (0x10000000+0x1de91c) [0x101de91c]
(EE) 5: Xvnc (GetPointerEvents+0xfff06f80) [0x101e0120]
(EE) 6: Xvnc (QueuePointerEvents+0xfff0741c) [0x101e05cc]
(EE) 7: Xvnc (_ZN11InputDevice11PointerMoveERKN3rfb5PointE+0xffe8d06c) [0x10160acc]
(EE) 8: Xvnc (_ZN14XserverDesktop12pointerEventERKN3rfb5PointEi+0xffe86d74) [0x1015a394]
(EE) 9: Xvnc (_ZN3rfb16VNCSConnectionST12pointerEventERKNS_5PointEi+0xffebc9b4) [0x10192b44]
(EE) 10: Xvnc (_ZN3rfb10SMsgReader16readPointerEventEv+0xffecedd4) [0x101a5ad4]
(EE) 11: Xvnc (_ZN3rfb12SMsgReaderV37readMsgEv+0xffeaad04) [0x10180264]
(EE) 12: Xvnc (_ZN3rfb11SConnection10processMsgEv+0xffeaa154) [0x1017f5b4]
(EE) 13: Xvnc (_ZN3rfb16VNCSConnectionST15processMessagesEv+0xffebf62c) [0x101959ec]
(EE) 14: Xvnc (_ZN3rfb11VNCServerST18processSocketEventEPN7network6SocketE+0xffe99d14) [0x1016e5d4]
(EE) 15: Xvnc (_ZN14XserverDesktop13wakeupHandlerEP6fd_seti+0xffe88aa8) [0x1015c2a8]
(EE) 16: Xvnc (0x10000000+0x1522a8) [0x101522a8]
(EE) 17: Xvnc (WakeupHandler+0xffef0f00) [0x101c9340]
(EE) 18: Xvnc (WaitForSomething+0xfff4793c) [0x1022310c]
(EE) 19: Xvnc (Dispatch+0xffeeb258) [0x101c32d8]
(EE) 20: Xvnc (main+0xffd70af0) [0x10043a40]
(EE) 21: /lib64/libc.so.6 (0x3fff9eff0000+0x4438c) [0x3fff9f03438c]
(EE) 22: /lib64/libc.so.6 (__libc_start_main+0xffe62ff4) [0x3fff9f0345b4]
(EE)
(EE) Segmentation fault at address 0x3fff00000004

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting
Comment 1 IBM Bug Proxy 2013-05-31 08:42:54 EDT
Created attachment 755252 [details]
logs from /tmp
Comment 2 Adam Jackson 2013-05-31 15:28:30 EDT
This backtrace is... sketchy.  There's no call chain in xserver by which we can get from fill_pointer_events (in frame 4) to GetEventMask, at least not that I can find.

Assuming I can trust this backtrace, I think it's the -> bit of:

Mask
GetEventMask(DeviceIntPtr dev, xEvent *event, InputClients * other)
{
    int evtype;

    /* XI2 filters are only ever 8 bit, so let's return a 8 bit mask */
    if ((evtype = xi2_get_type(event))) {
        return GetXI2MaskByte(other->xi2mask, dev, evtype);
    // ...

Which suggests 'other' is busted somehow.
Comment 3 IBM Bug Proxy 2013-05-31 15:43:09 EDT
------- Comment From baude@us.ibm.com 2013-05-31 19:38 EDT-------
Adam, at the risk of being redundant, i want to make sure everyone understands this is observed (right now) only with the install media.  Is there something diff about the x stack on the media vs runtime?
Comment 4 Benjamin Herrenschmidt 2013-05-31 17:40:01 EDT
The backtrace is probably wrong near the top, ie, I'd say

(EE) 5: Xvnc (GetPointerEvents+0xfff06f80) [0x101e0120]

Is more likely to be correct than GetEventMask.

You should enable show_unhandled_signals in the ppc kernels. I've enabled
it upstream in 3.10, I don't know why we didn't have it on by default but
I think it can be done via a command line argument.

At least the kernel would show you exactly the PC value of the segfault
which would help sorting out what's right and what not in the backtrace.
Comment 5 IBM Bug Proxy 2013-06-03 05:24:57 EDT
------- Comment From kamaleshb@in.ibm.com 2013-06-03 09:10 EDT-------
(In reply to comment #9)
> The backtrace is probably wrong near the top, ie, I'd say
>
> (EE) 5: Xvnc (GetPointerEvents+0xfff06f80) [0x101e0120]
>
> Is more likely to be correct than GetEventMask.
>
> You should enable show_unhandled_signals in the ppc kernels. I've enabled
> it upstream in 3.10, I don't know why we didn't have it on by default but
> I think it can be done via a command line argument.

echo 1 > /proc/sys/debug/exception-trace
Comment 6 IBM Bug Proxy 2013-06-21 07:22:39 EDT
------- Comment From iranna.ankad@in.ibm.com 2013-06-21 11:16 EDT-------
It is quite some time, there are no updates on this bug.

Any idea, if fix for this issue is already available or being worked on?

Thanks!
Comment 7 Tim Waugh 2013-06-21 11:04:05 EDT
This might have been fixed in 1.2.80-0.15.201314svn5065:

* Sat Jun 08 2013 Dennis Gilmore <dennis@ausil.us> 1.2.80-0.15.20130314svn5065
- bump to rebuild and pick up bugfix causing X to crash on ppc and arm

https://admin.fedoraproject.org/updates/FEDORA-2013-10453

This was pushed to stable a few days ago (16th).  Unfortunately I don't think there are nightly composes for ppc/ppc64 to be able to test it at the moment.
Comment 8 IBM Bug Proxy 2013-10-10 09:22:22 EDT
------- Comment From iranna.ankad@in.ibm.com 2013-10-10 13:14 EDT-------
Well..I verified this bug on the latest Fedora20 Alpha build (3.11.0-300.fc20) & I could not recreate the issue. I could successfully do VNC installation.

Thanks!
Comment 9 Tim Waugh 2013-10-10 10:08:30 EDT
Great. Thanks for re-testing.

Note You need to log in before you can comment on or make changes to this bug.