|
Bugzilla – Full Text Bug Listing |
| Summary: | xrdp: X11rdp: segfault at attempted login from Win2008 Server | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.3 | Reporter: | Greg Freemyer <Greg.Freemyer> |
| Component: | X11 Applications | Assignee: | Stephan Kulow <coolo> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | dimstar, hwit, jfrickson, moby, simon.crute, vkrevs |
| Version: | Final | ||
| Target Milestone: | Final | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 11.3 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Image of Sax2 window | ||
|
Description
Greg Freemyer
2009-01-19 23:25:08 UTC
I see the same issue when connecting from Windows Server 2003 and Windows XP. In my case, xrdp is running on 32 bit kernel version 2.6.27.7-9-pae. Same here on openSUSE 11.1 for x86_64 with the stock kernel. Jan 21 13:28:14 stal-dev-lx1 kernel: X11rdp[26410]: segfault at 30 ip 000000000042fa6b sp 00007fffe0308860 error 4 in X11rdp[400000+163000] Installing updated xrdp packages from http://download.opensuse.org/repositories/home:/hfiguiere:/Factory/openSUSE_11.1/ does not fix the problem. Updating to xrdp-0.4.1-61.1 fixes the segfault issue for me. Still have issues with not being able to connect unless a screen depth of 24 can be supported on the rdesktop client, and noticing some weird behavior at times with the mouse, but those are probably more fodder for bugzilla than being taged onto this bug. Unfortunately, updating to xrdp-0.4.1-61.1 does not fix the segfault issue for me. Same results (with M$-XP mstsc) Gets openSUSE_background (in connection log) Connecting to ip 127.0.1 port 3350 sesman connect ok sending login infi to sesman login succesful for display 10 started connecting rdpx11 channel is not present (session hangs) /var/log/xrdp-sesman.log: [20090129-13:31:55] [INFO ] granted TS access to user u00m763 [20090129-13:31:55] [INFO ] starting Xdmx session... [20090129-13:31:55] [CORE ] X server running - user u00m763 - pid 6503 [20090129-13:31:55] [INFO ] starting xrdp-sessvc - xpid=6503 - wmpid=6508 /var/log/messages: Jan 29 13:31:55 kc3055 xrdp-sesman: pam_warn(xrdp-sesman:session): function=[pam_sm_open_session] service=[xrdp-sesman] terminal=[:11] user=[u00m763] ruser =[<unknown>] rhost=[<unknown>] Jan 29 13:31:55 kc3055 kernel: X11rdp[6543]: segfault at 30 ip 000000000042fa6b sp 00007fff96d99be0 error 4 in X11rdp[400000+163000] I'm seeing this connecting to a sled11-rc2 x86_64 machine. ==> /var/log/messages <== Feb 2 10:25:08 linux-jb18 kernel: X11rdp[32564]: segfault at 30 ip 000000000042fa6b sp 00007fff08234f90 error 4 in X11rdp[400000+163000] Hmm, I wonder - does xrdp work for anyone at all? Seems to be completely broken ... Yes it does :) I just tested xrdp-0.4.1-16.7.1 (I think that was part of today's security update). Still no joy. I also tried xrdp-0.4.1-61.1 with no luck. I continue to only test from a Win2008 client, but obviously others are seeing failures with other MS clients. tried to sled11-rc3, no joy. From the same winXP client I can get to xrdp on my opensuse11.1 box on my home network. please try the latest versions of xrdp, xorg-x11-server-rdp and xorg-x11-server-dmx available from here: http://build.opensuse.org/project/show?project=home%3Adreveman%3Anomad X11rdp, is provided by the xorg-x11-server-rdp package so updating just xrdp wont help. You can use this command: $ rpm -q --changelog xorg-x11-server-rdp | grep x86-64 to verify that you have a version of X11rdp that contains a fix for this issue. The output of that command should contain: - Fix x86-64 brokenness. (bnc#466369) It wouldn't install
# rpm -Uvh xorg-x11-server-dmx-7.3.99-13.1.x86_64.rpm xorg-x11-server-rdp-7.3.99-5.1.x86_64.rpm xrdp-0.4.1-27.1.x86_64.rpm
warning: xorg-x11-server-dmx-7.3.99-13.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 55680ed7
Preparing... ########################################### [100%]
file /usr/bin/Xdmx from install of xorg-x11-server-dmx-7.3.99-13.1.x86_64 conflicts with file from package xorg-x11-server-extra-7.4-19.4.x86_64
file /usr/share/man/man1/Xdmx.1.gz from install of xorg-x11-server-dmx-7.3.99-13.1.x86_64 conflicts with file from package xorg-x11-server-extra-7.4-19.4.x86_64
This is on SLED11, rc3 x86_64
I recommend adding the repo instead of installing the rpms manually. Something like this should work: $ zypper ar http://download.opensuse.org/repositories/home:/dreveman:/nomad/openSUSE_11.1 nomad $ zypper in -f xrdp xorg-x11-server-dmx xorg-x11-server-rdp Just tried the zypper commands at the CLI. Apparently a x86_64 version of xrdp is not available. === Building repository 'nomad' cache [done] Loading repository data... Reading installed packages... Package xorg-x11-server-dmx-7.3.99-26.1.x86_64 not found in repositories, cannot reinstall. Package xorg-x11-server-rdp-7.3.99-3.3.x86_64 not found in repositories, cannot reinstall. Resolving package dependencies... The following package is going to be upgraded: xrdp The following package is going to change vendor: xrdp Overall download size: 220.0 K. No additional space will be used or freed after the operation. Continue? [YES/no]: Retrieving package xrdp-0.4.1-68.1.x86_64 (1/1), 220.0 K (1.3 M unpacked) Retrieving: xrdp-0.4.1-68.1.x86_64.rpm [error] File './x86_64/xrdp-0.4.1-68.1.x86_64.rpm' not found on medium 'http://download.opensuse.org/repositories/home:/hfiguiere:/Factory/openSUSE_11.1/' I installed the packages in comment 14 with zypper. xorg-x11-server-rdp-7.3.99-5.1 xrdp-0.4.1-27.1 compiz-plugins-dmx-0.1.0-8.18 xorg-x11-server-dmx-7.3.99-13.1 and I nolonger get the segfault. I still can't login though. /var/log/messages has Feb 17 09:34:29 linux-bliy xrdp-sesman: pam_warn(xrdp-sesman:session): function=[pam_sm_open_session] service=[xrdp-sesman] terminal=[:10] user=[scrute] ruser=[<unknown>] rhost=[<unknown>] and /var/log/xrdp-sesman.log has [20090217-09:34:29] [INFO ] granted TS access to user scrute [20090217-09:34:29] [INFO ] starting Xdmx session... [20090217-09:34:29] [CORE ] error X server died - user scrute - pid 6233 the client screen just has "login failed" on it. With RC4 I don't get the errors when logging into xrdp so it looks like it's fixed to me. (In reply to comment #17) > With RC4 I don't get the errors when logging into xrdp so it looks like it's > fixed to me. I hope you remembered to test it on x86_64 ? What is RC4? I think the factory kernel went straight from 2.6.27 to 2.6.29-rc5 so I assume that the kernel is not what your talking about. Sorry, I forgot I was commenting on a bug raised against openSUSE, not SLED. I work for Novell IS&T not the Engineering team, so I'm not much more than a regular user here :) The comments were aimed at telling the developer that with SLED11-RC$ I wasn't seeing the failure to login any more. and that his fixes had fixed the segfault. Although, comment 18 has made me wonder if I did test 64bit... I'll double check tomorrow. OK. So, forget what I said in comment17. I was testing on 32bit then (Doh!) Testing on sled11-rc4-x86_64 this morning, and I got errors when logging in. I've updated to the RPMs in Davids repo on comment 14, and get a different set of errors :) ==> /var/log/messages <== Feb 19 10:53:28 linux-ujlc xrdp-sesman: pam_warn(xrdp-sesman:session): function=[pam_sm_open_session] service=[xrdp-sesman] terminal=[:10] user=[scrute] ruser=[<unknown>] rhost=[<unknown>] ==> /var/log/xrdp-sesman.log <== [20090219-10:53:28] [INFO ] granted TS access to user scrute [20090219-10:53:28] [INFO ] starting Xdmx session... [20090219-10:53:28] [CORE ] error X server died - user scrute - pid 26998 I'm getting different results each time I try this. I rebooted everything, logged into the target system as root, then tried to rdesktop into it as my user. in /var/log/messages I get loads of Feb 19 11:25:40 linux-ujlc kernel: FAT: Directory bread(block 472) failed Feb 19 11:25:40 linux-ujlc kernel: attempt to access beyond end of device Feb 19 11:25:40 linux-ujlc kernel: sda1: rw=0, want=442, limit=2 error messages. In /var/log/xrdp-sesman.log it looks like it worked OK. [20090219-11:25:29] [INFO ] granted TS access to user scrute [20090219-11:25:29] [INFO ] starting Xdmx session... [20090219-11:25:29] [CORE ] X server running - user scrute - pid 7967 [20090219-11:25:30] [INFO ] starting xrdp-sessvc - xpid=7967 - wmpid=7997 [20090219-11:25:30] [CORE ] using keyboard layout: 0x809 (gb) [20090219-11:25:43] [INFO ] session 7966 - user scrute - terminated But no segfaults anywhere. I *think* these are now different problems. I'll log more bugs on these. You'll be able to get much more detailed information from xrdp-sesman if your run it from a terminal using: $ /usr/sbin/xrdp-sesman -n you'll first have to kill the existing instance of sesman using: $ /usr/sbin/xrdp-sesman -k I got the upgrade to go in, so I should be running your latest.
Still no joy for me either.
# /usr/sbin/xrdp-sesman -n
starting sesman in foregroud...
sesman config:
ListenAddress: 127.0.0.1
ListenPort: 3350
EnableUserWindowManager: 1
UserWindowManager: startwm.sh
DefaultWindowManager: startwm.sh
AuthFilePath: disabled
Xvnc parameters:
Parameter 00 -bs
X11rdp parameters:
Parameter 00 -bs
Xdmx parameters:
Parameter 00 -br
Parameter 01 -nolisten
Parameter 02 tcp
Parameter 03 --
Parameter 04 /usr/bin/Xfake
logging configuration:
LogFile: /var/log/xrdp-sesman.log
LogLevel: 4
EnableSyslog: 0
SyslogLevel: 4
security configuration:
AllowRootLogin: 1
MaxLoginRetry: 4
No TSUsersGroup defined
No TSAdminsGroup defined
session configuration:
MaxSessions: 10
KillDisconnected: 0
IdleTimeLimit: 0
DisconnectedTimeLimit: 0
[20090224-17:59:04] [WARN ] [init:45] libscp initialized
[20090224-17:59:04] [CORE ] starting sesman with pid 4168
[20090224-17:59:05] [INFO ] listening...
[20090224-17:59:19] [INFO ] granted TS access to user gaf
[20090224-17:59:19] [INFO ] starting Xdmx session...
pam_open_session failed: Cannot make/remove an entry for the specified session
(II) dmx: Generation: 1
(II) dmx: DMX digest: b85f0621ec70ffc1206c2b177fddb58b437994ef
(II) dmx: DMX version: 1.2.20070424 (DMX Project)
(II) dmx: DMX Build OS: openSUSE (SUSE LINUX)
(II) dmx: DMX Build Compiler: gcc 4.3.2
(II) dmx: DMX Execution OS: Linux 2.6.27.7-9-default #1 SMP 2008-12-04 18:10:04 +0100
(II) dmx: DMX Execution Host: tiger3-64bit
(II) dmx: MAXSCREENS: 16
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/tiger3-64bit:63
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
(II) dmx: Adding 4 detached displays
[config/dbus] couldn't take over org.x.config: org.freedesktop.DBus.Error.AccessDenied (Connection ":1.863" is not allowed to own the service "org.x.config.display63" due to security policies in the configuration file)
(II) dmx[o0/:63/Xfake]: Name of display: :63.0
(II) dmx[o0/:63/Xfake]: Version number: 11.0
(II) dmx[o0/:63/Xfake]: Vendor string: The X.Org Foundation
(II) dmx[o0/:63/Xfake]: Vendor release: 10599001
(II) dmx[o0/:63/Xfake]: Dimensions: 800x600 pixels
(II) dmx[o0/:63/Xfake]: 7 depths on screen 0: 1,4,8,15,16,24,32
(II) dmx[o0/:63/Xfake]: Depth of root window: 24 planes (24)
(II) dmx[o0/:63/Xfake]: Number of colormaps: 1 min, 1 max
(II) dmx[o0/:63/Xfake]: Options: backing-store no, save-unders no
(II) dmx[o0/:63/Xfake]: 800x600 on 800x600 at depth=24, bpp=32
(II) dmx[o0/:63/Xfake]: 0x21 TrueColor 24b 8b/rgb 256 0xff0000 0xff00 0x00ff *
(II) dmx[o0/:63/Xfake]: 0x3b TrueColor 32b 8b/rgb 256 0xff0000 0xff00 0x00ff
(II) dmx[o0/:63/Xfake]: XVIDEO: using image format:
(II) dmx[o0/:63/Xfake]: id: 0x32315659 (YV12)
(II) dmx[o0/:63/Xfake]: bits per pixel: 12
(II) dmx[o0/:63/Xfake]: number of planes: 3
(II) dmx[o0/:63/Xfake]: type: YUV (planar)
(II) dmx[o0/:63/Xfake]: XVIDEO: using image format:
(II) dmx[o0/:63/Xfake]: id: 0x32595559 (YUY2)
(II) dmx[o0/:63/Xfake]: bits per pixel: 16
(II) dmx[o0/:63/Xfake]: number of planes: 1
(II) dmx[o0/:63/Xfake]: type: YUV (packed)
(II) dmx[o1//]: XVIDEO: using image format:
(II) dmx[o1//]: id: 0x32315659 (YV12)
(II) dmx[o1//]: bits per pixel: 12
(II) dmx[o1//]: number of planes: 3
(II) dmx[o1//]: type: YUV (planar)
(II) dmx[o1//]: XVIDEO: using image format:
(II) dmx[o1//]: id: 0x32595559 (YUY2)
(II) dmx[o1//]: bits per pixel: 16
(II) dmx[o1//]: number of planes: 1
(II) dmx[o1//]: type: YUV (packed)
(II) dmx[o2//]: XVIDEO: using image format:
(II) dmx[o2//]: id: 0x32315659 (YV12)
(II) dmx[o2//]: bits per pixel: 12
(II) dmx[o2//]: number of planes: 3
(II) dmx[o2//]: type: YUV (planar)
(II) dmx[o2//]: XVIDEO: using image format:
(II) dmx[o2//]: id: 0x32595559 (YUY2)
(II) dmx[o2//]: bits per pixel: 16
(II) dmx[o2//]: number of planes: 1
(II) dmx[o2//]: type: YUV (packed)
(II) dmx[o3//]: XVIDEO: using image format:
(II) dmx[o3//]: id: 0x32315659 (YV12)
(II) dmx[o3//]: bits per pixel: 12
(II) dmx[o3//]: number of planes: 3
(II) dmx[o3//]: type: YUV (planar)
(II) dmx[o3//]: XVIDEO: using image format:
(II) dmx[o3//]: id: 0x32595559 (YUY2)
(II) dmx[o3//]: bits per pixel: 16
(II) dmx[o3//]: number of planes: 1
(II) dmx[o3//]: type: YUV (packed)
(II) dmx[o4//]: XVIDEO: using image format:
(II) dmx[o4//]: id: 0x32315659 (YV12)
(II) dmx[o4//]: bits per pixel: 12
(II) dmx[o4//]: number of planes: 3
(II) dmx[o4//]: type: YUV (planar)
(II) dmx[o4//]: XVIDEO: using image format:
(II) dmx[o4//]: id: 0x32595559 (YUY2)
(II) dmx[o4//]: bits per pixel: 16
(II) dmx[o4//]: number of planes: 1
(II) dmx[o4//]: type: YUV (packed)
(II) dmx: XSync batching with 100 ms interval
(II) dmx[o0/:63/Xfake]: DPMS 1.1 (not DPMS capable)
(II) dmx[o0/:63/Xfake]: Using MIT-SHM extension
(II) dmx: RandR 1.2 is present
(II) dmx[o0/:63/Xfake]: XVIDEO: No usable back-end adaptors found for 'DMX Video'
(II) dmx: ===== Start of Summary =====
(II) dmx: 5 screens configured with Xinerama (800 600)
(II) dmx: 0 visuals at depth 1:
(II) dmx: 0 visuals at depth 4:
(II) dmx: 0 visuals at depth 8:
(II) dmx: 0 visuals at depth 15:
(II) dmx: 0 visuals at depth 16:
(II) dmx: 1 visuals at depth 24:
(II) dmx: 0x21 TrueColor 24b 8b/rgb 256 0xff0000 0xff00 0x00ff
(II) dmx: 1 visuals at depth 32:
(II) dmx: 0x22 TrueColor 32b 8b/rgb 256 0xff0000 0xff00 0x00ff
(II) dmx: ===== End of Summary =====
[20090224-17:59:19] [CORE ] X server running - user gaf - pid 4178
[20090224-17:59:20] [INFO ] starting xrdp-sessvc - xpid=4178 - wmpid=4186
[20090224-17:59:20] [CORE ] using keyboard layout: 0x409 (us)
(II) dmx: ===== Start of Summary =====
(II) dmx: 5 screens configured with Xinerama (1180 900)
(II) dmx: 0 visuals at depth 1:
(II) dmx: 0 visuals at depth 4:
(II) dmx: 0 visuals at depth 8:
(II) dmx: 0 visuals at depth 15:
(II) dmx: 0 visuals at depth 16:
(II) dmx: 1 visuals at depth 24:
(II) dmx: 0x21 TrueColor 24b 8b/rgb 256 0xff0000 0xff00 0x00ff
(II) dmx: 1 visuals at depth 32:
(II) dmx: 0x22 TrueColor 32b 8b/rgb 256 0xff0000 0xff00 0x00ff
(II) dmx: ===== End of Summary =====
[sessvc] Setting signal handler
[sessvc] Waiting for X (pid 4178) and WM (pid 4186)
(II) dmx[o1//]: Attaching screen #1
(II) dmx[o1//]: Name of display: :22.0
(II) dmx[o1//]: Version number: 11.0
(II) dmx[o1//]: Vendor string: The X.Org Foundation
(II) dmx[o1//]: Vendor release: 10599001
(II) dmx[o1//]: Dimensions: 1180x900 pixels
(II) dmx[o1//]: 7 depths on screen 0: 16,1,4,8,15,24,32
(II) dmx[o1//]: Depth of root window: 16 planes (16)
(II) dmx[o1//]: Number of colormaps: 1 min, 1 max
(II) dmx[o1//]: Options: backing-store no, save-unders no
(II) dmx[o1//]: 1180x900 on 1180x900 at depth=16, bpp=16
(II) dmx[o1//]: 0x21 TrueColor 16b 8b/rgb 64 0xf800 0x07e0 0x001f *
(II) dmx[o1//]: 0x22 DirectColor 16b 8b/rgb 64 0xf800 0x07e0 0x001f
(II) dmx[o1//]: 0x3c TrueColor 32b 8b/rgb 256 0xff0000 0xff00 0x00ff
(**) dmx: Screen depth is not 24
(**) dmx: New screen data () does not match previously
(**) dmx: attached screen data
(**) dmx: All data must match in order to attach to screen #1
the last 4 lines explains why it doesn't work. the nomad channel can only be established when the client X server uses the same depth as the remote session. xrdp sessions use depth 24 by default. your local X server uses depth 16 for some reason. you'll have to change the depth of either the local or remote X server. I recommend changing the local X server as anything but depth 24 on the remote side is not really supported. btw, you should have seen the "Screen depth is not 24" message in the rdesktop window as well. was that not the case? and if you're using a recent version of xrdp (changelog entry from Jan 22 or later) it should automatically fall-back to a normal RDP connection in a case like this when the nomad channel connection couldn't be established. Created attachment 275823 [details]
Image of Sax2 window
I'm confused.
1) I just fired up sax2 to change to 24-bit color. It looks to me like it is already set. I have not changed it.
2) I did see the "not in 24-bit mode" message, but it looked like a standard info message, not a "I'm aborting because you have an unsupported mode" message.
3) No fall back occurred
No comment in a few weeks. Since the segfault is gone, but the failure to identify my setup as 24-bit persists, should I create a new bug? I'm still getting the segfault. ==> /var/log/messages <== 2009-12-13 03:29:49 -06:00 <kern.info> vervet kernel: X11rdp[1722]: segfault at 30 ip 000000000042fa6b sp 00007fff6173c730 error 4 in X11rdp[400000+163000] Connecting from WinXP to OpenSUSE 11.1 x86_64 How do I set the color depth on a newly create xrdp window? == details 18 months later, I've upgraded to oS 11.3 and I still can't get rdp to work. My /var/log/xrdp-sesman.log file ends with: [sessvc] Waiting for X (pid 24018) and WM (pid 24023) (II) dmx[o1//]: Attaching screen #1 (II) dmx[o1//]: Using 5 second response timeout (II) dmx[o1//]: Name of display: :20.0 (II) dmx[o1//]: Version number: 11.0 (II) dmx[o1//]: Vendor string: The X.Org Foundation (II) dmx[o1//]: Vendor release: 10599001 (II) dmx[o1//]: Dimensions: 1180x900 pixels (II) dmx[o1//]: 7 depths on screen 0: 16,1,4,8,15,24,32 (II) dmx[o1//]: Depth of root window: 16 planes (16) (II) dmx[o1//]: Number of colormaps: 1 min, 1 max (II) dmx[o1//]: Options: backing-store no, save-unders no (II) dmx[o1//]: 1180x900 on 1180x900 at depth=16, bpp=16 (II) dmx[o1//]: 0x21 TrueColor 16b 8b/rgb 64 0xf800 0x07e0 0x001f * (II) dmx[o1//]: 0x22 DirectColor 16b 8b/rgb 64 0xf800 0x07e0 0x001f (II) dmx[o1//]: 0x3c TrueColor 32b 8b/rgb 256 0xff0000 0xff00 0x00ff (**) dmx: Screen depth is not 24 (**) dmx: New screen data () does not match previously (**) dmx: attached screen data (**) dmx: All data must match in order to attach to screen #1 So the new X screen created is 16-bit color, not 24-bit. But my normal KDE login screen is 24-bit per: # xdpyinfo | grep depths depths (7): 24, 1, 4, 8, 15, 16, 32 I don't think this bug is going to be fixed. |