Bug 1282009
Summary: | ** stack smashing detected ***: x11vnc terminated | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Davide Repetto <red> | ||||||||
Component: | libvncserver | Assignee: | Rex Dieter <rdieter> | ||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | unspecified | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 28 | CC: | DaveRedHatBugzilla, mp, pahan, peter.green, ppisar, psppsn96, rdieter, trevor, wunderle24 | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2019-05-12 11:04:38 UTC | Type: | Bug | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Davide Repetto
2015-11-14 07:15:19 UTC
Please test new version: https://bodhi.fedoraproject.org/updates/FEDORA-2015-6685346aaa It does not solve this issue, though it solves bug #1118353. It may help to know that in my setups the crash happens even more often if the invocation is as follows: # x11vnc -display :0 -auth /var/run/lightdm/root/:0 -repeat -cursor -nowireframe -scrollcopyrect always -ultrafilexfer -tightfilexfer -chatwindow -connect dave.idp.it In this case, just clicking on the upper left menus in the mate-panel will trigger the crash. Also, I'm using remmina as the vnc client - in case it makes any difference. It seams equal to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735648 https://bugs.launchpad.net/ubuntu/+source/x11vnc/+bug/1175098 And by comments it works if compilled with bundled libvncserver. So, reassigning. Dupe of #1278335? I just netinstalled a Fedora 24 installation on a Dell Inspiron N4010, and am also affected by this issue (similar backtrace and such). I am using x11vnc version 0.9.14 from the fedora repository. This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. (In reply to Fedora End Of Life from comment #6) > This message is a reminder that Fedora 23 is nearing its end of life. > Approximately 4 (four) weeks from now Fedora will stop maintaining > and issuing updates for Fedora 23. It is Fedora's policy to close all > bug reports from releases that are no longer maintained. At that time > this bug will be closed as EOL if it remains open with a Fedora 'version' > of '23'. > > Package Maintainer: If you wish for this bug to remain open because you > plan to fix it in a currently maintained version, simply change the > 'version' > to a later Fedora version. > > Thank you for reporting this issue and we are sorry that we were not > able to fix it before Fedora 23 is end of life. If you would still like > to see this bug fixed and are able to reproduce it against a later version > of Fedora, you are encouraged change the 'version' to a later Fedora > version prior this bug is closed as described in the policy above. > > Although we aim to fix as many bugs as possible during every release's > lifetime, sometimes those efforts are overtaken by events. Often a > more recent Fedora release includes newer upstream software that fixes > bugs or makes them obsolete. This is reproducible in Fedora 24. However, I am either incompetent with Bugzilla or do not have permission to change the fields. (In reply to Kyle Marek from comment #7) > However, I am either incompetent with > Bugzilla or do not have permission to change the fields. You are not the only one. I've already seen another person complaining about it. Probably some bug in Bugzilla. I switched the version on you behalf. Created attachment 1244122 [details]
kmarek.x11vnc.stack.smash.1485305814.log
Fedora 25
Created attachment 1244123 [details]
kmarek.rpm.installed.1485305814.log
Fedora 25
I haven't noticed much of this bug any more running x11vnc-0.9.14-2.fc24.x86_64 and libvncserver-0.9.11-2.fc25.1.x86_64 on Fedora 25, and I am connected to my main computer with VNC nearly every day. I guess I will have to consciously interact with VNC more to be more certain, but I thought I'd mention this in case anyone else wants to take another look at their use cases. I too have not seen this bug in a long while (like 6-10 months) (using F24 now) and have a VNC open most of the time, but with light use. I too suspect that this was fixed somewhere along the way. But I'm not positive. I spoke too soon... the stack smashing just hit again for me today. I'll attach the debug output. Created attachment 1292075 [details]
log of latest smash
Does abrt ever catch any uploadable dumps? I don't run abrt (I uninstall on purpose). If I should to capture something useful, point me to a quick howto if such a thing exists? I'm pretty sure I can recreate this bug pretty easily on demand now. I'm not totally familiar with setting abrt up, so I do not think I can offer any instructions as of this time. Maybe I'll have something soon. Reproduction of this issue seems to be hit and miss or hardware dependent, so I think linking a coredump upload would help developers. I believe abrt automatically captures any crash with the packages installed. I do not know what packages are necessary, so here's what I have installed. $ rpm -qa | grep -i abrt abrt-addon-python3-2.9.0-1.fc25.x86_64 abrt-addon-coredump-helper-2.9.0-1.fc25.x86_64 abrt-retrace-client-2.9.0-1.fc25.x86_64 abrt-gui-libs-2.9.0-1.fc25.x86_64 gnome-abrt-1.2.5-1.fc25.x86_64 abrt-2.9.0-1.fc25.x86_64 abrt-addon-pstoreoops-2.9.0-1.fc25.x86_64 abrt-libs-2.9.0-1.fc25.x86_64 abrt-addon-kerneloops-2.9.0-1.fc25.x86_64 abrt-tui-2.9.0-1.fc25.x86_64 abrt-addon-vmcore-2.9.0-1.fc25.x86_64 abrt-dbus-2.9.0-1.fc25.x86_64 abrt-addon-xorg-2.9.0-1.fc25.x86_64 abrt-addon-ccpp-2.9.0-1.fc25.x86_64 abrt-desktop-2.9.0-1.fc25.x86_64 abrt-python3-2.9.0-1.fc25.x86_64 abrt-cli-2.9.0-1.fc25.x86_64 eclipse-abrt-0.0.3-1.fc25.noarch abrt-plugin-bodhi-2.9.0-1.fc25.x86_64 abrt-gui-2.9.0-1.fc25.x86_64 In the meantime, I'll see if this can be reproduced at all with some VMs. This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Applies to Fedora 25. Haven't seen yet in Fedora 26. Please update version field accordingly. Confirmed Still in F25. This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Confirmed Still in FC27 Reporting another Fedora 27 occurrence, this time no backtrace though: λ ~/ x11vnc -ncache_cr ############################################################### #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@# #@ @# #@ ** WARNING ** WARNING ** WARNING ** WARNING ** @# #@ @# #@ YOU ARE RUNNING X11VNC WITHOUT A PASSWORD!! @# #@ @# #@ This means anyone with network access to this computer @# #@ may be able to view and control your desktop. @# #@ @# #@ >>> If you did not mean to do this Press CTRL-C now!! <<< @# #@ @# #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@# #@ @# #@ You can create an x11vnc password file by running: @# #@ @# #@ x11vnc -storepasswd password /path/to/passfile @# #@ or x11vnc -storepasswd /path/to/passfile @# #@ or x11vnc -storepasswd @# #@ @# #@ (the last one will use ~/.vnc/passwd) @# #@ @# #@ and then starting x11vnc via: @# #@ @# #@ x11vnc -rfbauth /path/to/passfile @# #@ @# #@ an existing ~/.vnc/passwd file from another VNC @# #@ application will work fine too. @# #@ @# #@ You can also use the -passwdfile or -passwd options. @# #@ (note -passwd is unsafe if local users are not trusted) @# #@ @# #@ Make sure any -rfbauth and -passwdfile password files @# #@ cannot be read by untrusted users. @# #@ @# #@ Use x11vnc -usepw to automatically use your @# #@ ~/.vnc/passwd or ~/.vnc/passwdfile password files. @# #@ (and prompt you to create ~/.vnc/passwd if neither @# #@ file exists.) Under -usepw, x11vnc will exit if it @# #@ cannot find a password to use. @# #@ @# #@ @# #@ Even with a password, the subsequent VNC traffic is @# #@ sent in the clear. Consider tunnelling via ssh(1): @# #@ @# #@ http://www.karlrunge.com/x11vnc/#tunnelling @# #@ @# #@ Or using the x11vnc SSL options: -ssl and -stunnel @# #@ @# #@ Please Read the documention for more info about @# #@ passwords, security, and encryption. @# #@ @# #@ http://www.karlrunge.com/x11vnc/faq.html#faq-passwd @# #@ @# #@ To disable this warning use the -nopw option, or put @# #@ 'nopw' on a line in your ~/.x11vncrc file. @# #@ @# #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@# ############################################################### 24/11/2017 10:08:16 x11vnc version: 0.9.14 lastmod: 2013-11-21 pid: 19438 24/11/2017 10:08:16 Using X display :0 24/11/2017 10:08:16 rootwin: 0x134 reswin: 0x5e00001 dpy: 0xa17592c0 24/11/2017 10:08:16 24/11/2017 10:08:16 ------------------ USEFUL INFORMATION ------------------ 24/11/2017 10:08:16 X DAMAGE available on display, using it for polling hints. 24/11/2017 10:08:16 To disable this behavior use: '-noxdamage' 24/11/2017 10:08:16 24/11/2017 10:08:16 Most compositing window managers like 'compiz' or 'beryl' 24/11/2017 10:08:16 cause X DAMAGE to fail, and so you may not see any screen 24/11/2017 10:08:16 updates via VNC. Either disable 'compiz' (recommended) or 24/11/2017 10:08:16 supply the x11vnc '-noxdamage' command line option. 24/11/2017 10:08:16 24/11/2017 10:08:16 Wireframing: -wireframe mode is in effect for window moves. 24/11/2017 10:08:16 If this yields undesired behavior (poor response, painting 24/11/2017 10:08:16 errors, etc) it may be disabled: 24/11/2017 10:08:16 - use '-nowf' to disable wireframing completely. 24/11/2017 10:08:16 - use '-nowcr' to disable the Copy Rectangle after the 24/11/2017 10:08:16 moved window is released in the new position. 24/11/2017 10:08:16 Also see the -help entry for tuning parameters. 24/11/2017 10:08:16 You can press 3 Alt_L's (Left "Alt" key) in a row to 24/11/2017 10:08:16 repaint the screen, also see the -fixscreen option for 24/11/2017 10:08:16 periodic repaints. 24/11/2017 10:08:16 24/11/2017 10:08:16 XFIXES available on display, resetting cursor mode 24/11/2017 10:08:16 to: '-cursor most'. 24/11/2017 10:08:16 to disable this behavior use: '-cursor arrow' 24/11/2017 10:08:16 or '-noxfixes'. 24/11/2017 10:08:16 using XFIXES for cursor drawing. 24/11/2017 10:08:16 GrabServer control via XTEST. 24/11/2017 10:08:16 24/11/2017 10:08:16 Scroll Detection: -scrollcopyrect mode is in effect to 24/11/2017 10:08:16 use RECORD extension to try to detect scrolling windows 24/11/2017 10:08:16 (induced by either user keystroke or mouse input). 24/11/2017 10:08:16 If this yields undesired behavior (poor response, painting 24/11/2017 10:08:16 errors, etc) it may be disabled via: '-noscr' 24/11/2017 10:08:16 Also see the -help entry for tuning parameters. 24/11/2017 10:08:16 You can press 3 Alt_L's (Left "Alt" key) in a row to 24/11/2017 10:08:16 repaint the screen, also see the -fixscreen option for 24/11/2017 10:08:16 periodic repaints. 24/11/2017 10:08:16 24/11/2017 10:08:16 XKEYBOARD: number of keysyms per keycode 7 is greater 24/11/2017 10:08:16 than 4 and 192 keysyms are mapped above 4. 24/11/2017 10:08:16 Automatically switching to -xkb mode. 24/11/2017 10:08:16 If this makes the key mapping worse you can 24/11/2017 10:08:16 disable it with the "-noxkb" option. 24/11/2017 10:08:16 Also, remember "-remap DEAD" for accenting characters. 24/11/2017 10:08:16 24/11/2017 10:08:16 X FBPM extension not supported. 24/11/2017 10:08:16 X display is capable of DPMS. 24/11/2017 10:08:16 -------------------------------------------------------- 24/11/2017 10:08:16 24/11/2017 10:08:16 Default visual ID: 0x21 24/11/2017 10:08:16 Read initial data from X display into framebuffer. 24/11/2017 10:08:16 initialize_screen: fb_depth/fb_bpp/fb_Bpl 24/32/10240 24/11/2017 10:08:16 24/11/2017 10:08:16 X display :0 is 32bpp depth=24 true color 24/11/2017 10:08:16 24/11/2017 10:08:16 Autoprobing TCP port 24/11/2017 10:08:16 Autoprobing selected TCP port 5900 24/11/2017 10:08:16 Autoprobing TCP6 port 24/11/2017 10:08:16 Autoprobing selected TCP6 port 5900 24/11/2017 10:08:16 listen6: bind: Address already in use 24/11/2017 10:08:16 Not listening on IPv6 interface. 24/11/2017 10:08:16 24/11/2017 10:08:16 Xinerama is present and active (e.g. multi-head). 24/11/2017 10:08:16 Xinerama: number of sub-screens: 1 24/11/2017 10:08:16 Xinerama: no blackouts needed (only one sub-screen) 24/11/2017 10:08:16 24/11/2017 10:08:16 Number of screens: 1 for X11 display ':0' 24/11/2017 10:08:16 fb read rate: 1067 MB/sec 24/11/2017 10:08:16 fast read: reset -wait ms to: 10 24/11/2017 10:08:16 fast read: reset -defer ms to: 10 24/11/2017 10:08:16 The X server says there are 12 mouse buttons. 24/11/2017 10:08:16 screen setup finished. 24/11/2017 10:08:16 24/11/2017 10:08:16 WARNING: You are running x11vnc WITHOUT a password. See 24/11/2017 10:08:16 WARNING: the warning message printed above for more info. 24/11/2017 10:08:16 The VNC desktop is: localhost.localdomain:0 PORT=5900 ****************************************************************************** Have you tried the x11vnc '-ncache' VNC client-side pixel caching feature yet? The scheme stores pixel data offscreen on the VNC viewer side for faster retrieval. It should work with any VNC viewer. Try it by running: x11vnc -ncache 10 ... One can also add -ncache_cr for smooth 'copyrect' window motion. More info: http://www.karlrunge.com/x11vnc/faq.html#faq-client-caching 24/11/2017 10:08:39 Got connection from client 192.168.56.30 24/11/2017 10:08:39 other clients: 24/11/2017 10:08:39 Normal socket connection 24/11/2017 10:08:39 Disabled X server key autorepeat. 24/11/2017 10:08:39 to force back on run: 'xset r on' (3 times) 24/11/2017 10:08:39 incr accepted_client=1 for 192.168.56.30:53680 sock=11 24/11/2017 10:08:39 Client Protocol Version 3.8 24/11/2017 10:08:39 Protocol version sent 3.8, using 3.8 24/11/2017 10:08:39 rfbProcessClientSecurityType: executing handler for type 1 24/11/2017 10:08:39 rfbProcessClientSecurityType: returning securityResult for client rfb version >= 3.8 24/11/2017 10:08:39 copy_tiles: allocating first_line at size 81 24/11/2017 10:08:39 Enabling NewFBSize protocol extension for client 192.168.56.30 24/11/2017 10:08:39 Enabling LastRect protocol extension for client 192.168.56.30 24/11/2017 10:08:39 Enabling cursor position updates for client 192.168.56.30 24/11/2017 10:08:39 Enabling full-color cursor updates for client 192.168.56.30 24/11/2017 10:08:39 Using tight encoding for client 192.168.56.30 24/11/2017 10:08:40 client 1 network rate 10079.4 KB/sec (63515.2 eff KB/sec) 24/11/2017 10:08:40 client 1 latency: 0.9 ms 24/11/2017 10:08:40 dt1: 0.2032, dt2: 0.0294 dt3: 0.0009 bytes: 2340684 24/11/2017 10:08:40 link_rate: LR_LAN - 1 ms, 10079 KB/s 24/11/2017 10:08:40 client useCopyRect: 192.168.56.30 -1 24/11/2017 10:08:40 client_set_net: 192.168.56.30 0.0750 24/11/2017 10:08:40 created xdamage object: 0x5e00054 24/11/2017 10:08:48 created selwin: 0x5e00055 24/11/2017 10:08:48 called initialize_xfixes() ^[^[24/11/2017 10:08:54 cursor_noshape_updates_clients: 0 24/11/2017 10:08:59 cursor_noshape_updates_clients: 0 24/11/2017 10:08:59 cursor_noshape_updates_clients: 0 24/11/2017 10:09:01 cursor_noshape_updates_clients: 0 24/11/2017 10:09:17 cursor_noshape_updates_clients: 0 24/11/2017 10:15:28 idle keyboard: turning X autorepeat back on. 24/11/2017 10:39:02 active keyboard: turning X autorepeat off. 24/11/2017 10:58:12 idle keyboard: turning X autorepeat back on. 24/11/2017 10:58:26 active keyboard: waiting until all keys are up. key_down=47 semicolon. If the key is inaccessible via keyboard, consider 'x11vnc -R clear_all' 24/11/2017 10:58:26 active keyboard: waiting until all keys are up. key_down=50 Shift_L. If the key is inaccessible via keyboard, consider 'x11vnc -R clear_all' 24/11/2017 10:58:28 active keyboard: turning X autorepeat off. 24/11/2017 11:23:52 idle keyboard: turning X autorepeat back on. 24/11/2017 11:28:58 idle keyboard: turning X autorepeat back on. 24/11/2017 11:29:00 active keyboard: waiting until all keys are up. key_down=23 Tab. If the key is inaccessible via keyboard, consider 'x11vnc -R clear_all' 24/11/2017 11:29:00 active keyboard: waiting until all keys are up. key_down=64 Alt_L. If the key is inaccessible via keyboard, consider 'x11vnc -R clear_all' 24/11/2017 11:29:02 active keyboard: turning X autorepeat off. *** stack smashing detected ***: <unknown> terminated caught signal: 6 24/11/2017 11:29:09 deleted 80 tile_row polling images. 24/11/2017 11:29:09 Restored X server key autorepeat to: 1 If you compile from source, disabling the stack protection, then the issue doesn't re-occur. See the below gist for details: https://gist.github.com/mangoliou/407d6a39a60d128610c20c4143f39f0d I'm not certain what possible side effects this could have unfortunately. (In reply to Peter Green from comment #24) > If you compile from source, disabling the stack protection, then the issue > doesn't re-occur. See the below gist for details: > Of course. If you disable the security check, then the check does not happen and does not abort the process. That's like removing an indicator light and calling it a fix. To locate the bug we need either full back trace including (i.e. having installed the debuginfo packages for all the symbols in the stack and inspecting the core dump by gdb debugger) posted by the reporter or a reliable reproducer. (Telling what exact versions of packages are installed what commands were run, what action was done with keyboard or pointer. And also what crashes. Reading the comments, I'm not sure if this is about client or server.) Last I remember it happens to me inconsistently on clicks (I believe I have experienced it with buttons 1, 2, and 3). Does anybody else have any patterns in their crash triggers? (In reply to Petr Pisar from comment #25) > (In reply to Peter Green from comment #24) > > If you compile from source, disabling the stack protection, then the issue > > doesn't re-occur. See the below gist for details: > > > Of course. If you disable the security check, then the check does not happen > and does not abort the process. That's like removing an indicator light and > calling it a fix. > > To locate the bug we need either full back trace including (i.e. having > installed the debuginfo packages for all the symbols in the stack and > inspecting the core dump by gdb debugger) posted by the reporter or a > reliable reproducer. (Telling what exact versions of packages are installed > what commands were run, what action was done with keyboard or pointer. And > also what crashes. Reading the comments, I'm not sure if this is about > client or server.) Of course, I was simply suggesting a workaround! I have switched back to the Fedora repo supplied x11vnc binary for now to try and generate a backtrace for you. This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. |