xfwm4 crashed with SIGSEGV in clientTerminate()

Bug #1233107 reported by Gajendra Singh Gusain on 2013-09-30
48
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Xfwm4
Fix Released
Medium
xfwm4 (Ubuntu)
Medium
Unassigned

Bug Description

network file manager freezes

ProblemType: Crash
DistroRelease: Ubuntu 13.10
Package: xfwm4 4.10.1-1ubuntu1
ProcVersionSignature: Ubuntu 3.11.0-9.16-generic 3.11.2
Uname: Linux 3.11.0-9-generic x86_64
ApportVersion: 2.12.5-0ubuntu1
Architecture: amd64
Date: Mon Sep 30 16:39:42 2013
ExecutablePath: /usr/bin/xfwm4
InstallationDate: Installed on 2013-09-29 (0 days ago)
InstallationMedia: Xubuntu 13.10 "Saucy Salamander" - Beta amd64 (20130928)
MarkForUpload: True
ProcCmdline: xfwm4 --replace
ProcEnviron:
 LANGUAGE=en_IN:en
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_IN
 SHELL=/bin/bash
SegvAnalysis:
 Segfault happened at: 0x7f623b2c3ac6 <__strcmp_sse42+22>: movdqu (%rdi),%xmm1
 PC (0x7f623b2c3ac6) ok
 source "(%rdi)" (0x00000000) not located in a known VMA region (needed readable region)!
 destination "%xmm1" ok
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: xfwm4
StacktraceTop:
 ?? ()
 ?? ()
 g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
 ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
 g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
Title: xfwm4 crashed with SIGSEGV in g_main_context_dispatch()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

Related branches

StacktraceTop:
 clientTerminate (c=0x7f623fd1d100) at client.c:2582
 terminateProcessIO (channel=<optimized out>, condition=<optimized out>, data=0x7f623fd1d100) at terminate.c:82
 g_main_dispatch (context=0x7f623fc2dc00) at /build/buildd/glib2.0-2.38.0/./glib/gmain.c:3065
 g_main_context_dispatch (context=context@entry=0x7f623fc2dc00) at /build/buildd/glib2.0-2.38.0/./glib/gmain.c:3641
 g_main_context_iterate (context=0x7f623fc2dc00, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /build/buildd/glib2.0-2.38.0/./glib/gmain.c:3712

Changed in xfwm4 (Ubuntu):
importance: Undecided → Medium
summary: - xfwm4 crashed with SIGSEGV in g_main_context_dispatch()
+ xfwm4 crashed with SIGSEGV in clientTerminate()
tags: removed: need-amd64-retrace
tags: added: trusty
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xfwm4 (Ubuntu):
status: New → Confirmed
C de-Avillez (hggdh2) on 2014-03-18
information type: Private → Public
LAZA (laza74) wrote :

Happened on one of my Internet-Café machines with Precise 32 Bit.
--> added tags

tags: added: i386
tags: added: precise

Created attachment 5727
Determine max hostname

In display.c:

#define MAX_HOSTNAME_LENGTH 32

This includes the null byte, so the limit is really 31 characters. The real limit is 64+1 on Linux and 255+1 on BSD.

If the buffer is not big enough for the hostname, gethostname will return ENAMETOOLONG and the hostname will be set to NULL.

Later, when a client is killed, the hostname is tested with strcmp, which causes a segfault.

Example of the bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1085082

If you check the environment file posted, the hostname is 33 characters.

Patch is attached which uses HOST_NAME_MAX to determine the maximum hostname length. If not defined, it is defined to 255. From the gethostname (Linux) man page:

       SUSv2 guarantees that "Host names are limited to 255 bytes".
       POSIX.1-2001 guarantees that "Host names (not including the terminating
       null byte) are limited to HOST_NAME_MAX bytes". On Linux,
       HOST_NAME_MAX is defined with the value 64, which has been the limit
       since Linux 1.0 (earlier kernels imposed a limit of 8 bytes).

The patch also adds a warning if gethostname still fails, and a null check in when the hostname is tested.

Alistair Buxton (a-j-buxton) wrote :

This happens if your hostname is 32 characters or more. The limit on Linux is 64 characters, but xfwm has a hardcoded limit of 31. I've submitted a patch upstream which should fix this issue.

Changed in xfwm4:
importance: Unknown → Medium
status: Unknown → Confirmed

In order to test this you need a program which doesn't respond to NET_WM_PING.

A suitable test application is available here:

https://maemo.gitorious.org/fremantle-hildon-desktop/hildon-desktop/source/1be6ec951a4eed1d79878f88d2eacb298b447112:tests/test-hung-process.c

Compile it like this:

gcc -o test-hung-process test-hung-process.c `pkg-config --cflags --libs gtk+-2.0`

Run this command to set hostname:

sudo hostname aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Log out and log in again to update environment. (Don't restart, hostname is not saved.)

Now when you start a shell you should see your new, long, hostname.

Run the test application, and when the window opens, click the close button. After a few seconds Xfwm will ask if you want to kill it. Click "yes".

Without patch, Xfwm will segfault after you click "yes". It will then restart and the hung window will still exist.

With the patch, the process will be killed as expected, and Xfwm won't crash.

Thanks for the patch, I just verified your testcase here.
Pushed to master: http://git.xfce.org/xfce/xfwm4/commit/?id=19e9cc2db222fde7f138de86f3cedcda4a4d4295

Changed in xfwm4:
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xfwm4 - 4.11.3-0ubuntu1

---------------
xfwm4 (4.11.3-0ubuntu1) vivid; urgency=medium

  * New upstream release.
    - Fix maximizing vetically or horizontally tiled windows. LP: #1397922
    - Revert "Experiment with button events." LP: #1394439
    - Use source indication in activate window. LP: #1292122
    - Determine the maximum host name length correctly. LP: #1233107
  * Drop 0001-fix-fullscreen-qt4-behavior-bug-8563.patch,
    02-remove-unused-maximize-button.patch, fixed upstream
 -- Jackson Doak <email address hidden> Sun, 15 Feb 2015 06:24:16 +1100

Changed in xfwm4 (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.