Bug 100957

Summary:

Segfault on closing window

Product:

xorg

Reporter:

Andreas Reis <andreas.reis>

Component:

Server/General

Assignee:

Xorg Project Team <xorg-team>

Status:

RESOLVED FIXED

QA Contact:

Xorg Project Team <xorg-team>

Severity:

major

Priority:

medium

CC:

michel, sarnex

Version:

git

Hardware:

x86-64 (AMD64)

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
Xorg.0.log	none
backtrace	none
better backtrace	none
valgrind	none
Only mark client as ready if !client->clientGone	none
valgrind with patch	none

Description Andreas Reis 2017-05-07 10:46:28 UTC

Getting this for a week or so with git. It doesn't always occur, but seems mostly (always?) to happen on closing a program's main window.

(EE) Backtrace:
(EE) 0: /usr/lib/xorg-server/Xorg (OsSigHandler+0x29) [0x55dd0d3778f9]
(EE) 1: /usr/lib/libpthread.so.0 (funlockfile+0x50) [0x7ff07e0fb02f]
(EE) 2: /usr/lib/xorg-server/Xorg (ReadRequestFromClient+0x1c) [0x55dd0d3760cc]
(EE) 3: /usr/lib/xorg-server/Xorg (Dispatch+0x201) [0x55dd0d1d84b1]
(EE) 4: /usr/lib/xorg-server/Xorg (dix_main+0x388) [0x55dd0d1de1b8]
(EE) 5: /usr/lib/libc.so.6 (__libc_start_main+0xf1) [0x7ff07dd65511]
(EE) 6: /usr/lib/xorg-server/Xorg (_start+0x2a) [0x55dd0d1c26fa]
(EE) 
(EE) Segmentation fault at address 0x8

Comment 1 Andreas Reis 2017-05-07 10:46:51 UTC

Created attachment 131240 [details]
Xorg.0.log

Comment 2 Nick Sarnie 2017-05-07 22:55:09 UTC

Created attachment 131247 [details]
backtrace

Here is a better backtrace of this issue.

Comment 3 Michel Dänzer 2017-05-08 00:44:14 UTC

Comment on attachment 131247 [details]
backtrace

SIGPIPE is not a crash. Enter

 handle SIGPIPE nostop noprint

at the gdb prompt to make gdb ignore it.

Comment 4 Nick Sarnie 2017-05-08 01:43:25 UTC

Created attachment 131251 [details]
better backtrace

Sorry about that, the SIGABRT BT is attached now.

Comment 5 Michel Dänzer 2017-05-08 02:10:30 UTC

Thanks. That's a different crash from the one in the attached log file. It looks like there might be memory corruption going on, so trying to reproduce the problem with Xorg running in valgrind might give more information.

Comment 6 Nick Sarnie 2017-05-08 03:59:01 UTC

Created attachment 131252 [details]
valgrind

I've attached the log from valgrind.

Thanks,
Sarnex

Comment 7 Michel Dänzer 2017-05-09 02:46:56 UTC

Created attachment 131270 [details] [review]
Only mark client as ready if !client->clientGone

Does this patch fix the problem? Please attach the output of running the patched Xorg in valgrind either way.

Comment 8 Nick Sarnie 2017-05-09 17:11:07 UTC

Created attachment 131278 [details]
valgrind with patch

Unfortunately, the patch doesn't work for me. I attached the valgrind log with the patch.

Comment 9 Andreas Reis 2017-05-10 08:55:34 UTC

Been using the patch since yesterday, also still getting the crash.

Comment 10 Paul Menzel 2017-08-10 14:25:18 UTC

Commit d9e23ea4 (dix: Remove clients from input and output ready queues after closing) in the master branch references this bug report.

```
commit d9e23ea4228575344e3b4c0443cecc5eb75356e4
Author: Keith Packard <keithp@keithp.com>
Date:   Wed May 10 21:50:45 2017 -0700

    dix: Remove clients from input and output ready queues after closing
    
    Delay removing the client from these two queues until all potential
    I/O has completed in case we mark the client as ready for reading or
    with pending output during the close operation.
    
    Bugzilla: https://bugs.freedesktop.org/100957
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Tested-by: Nick Sarnie <commendsarnex@gmail.com>
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
```

Should the status be updated somehow?

Comment 11 Andreas Reis 2017-08-10 15:14:44 UTC

Yeah, hasn't affected me since ages.

Comment 12 Michel Dänzer 2017-08-14 03:32:25 UTC

Thanks for the report, fixed by the change referenced in comment 10.

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.