Bug 102106 - xorg crashes when running gscan2pdf (libgtk2-perl) test case
Summary: xorg crashes when running gscan2pdf (libgtk2-perl) test case
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-08 10:02 UTC by jffry
Modified: 2019-12-04 09:30 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description jffry 2017-08-08 10:02:59 UTC
* What led up to the situation?

Download and extract the source:

wget
http://http.debian.net/debian/pool/main/g/gscan2pdf/gscan2pdf_1.6.0.orig.tar.xz
tar xvfJ gscan2pdf_1.6.0.orig.tar.xz
cd gscan2pdf-1.6.0

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Run one of the test cases:

PERL5LIB="blib:lib:$PERL5LIB" perl t/114_cancel_save_pdf.t

   * What was the outcome of this action?

xorg crashed, and I was returned to the login screen

   * What outcome did you expect instead?

The test should have run through as normal

I tried to debug the problem by installing xserver-xorg-video-nouveau-dbg, ssh-
ing to the computer from another, starting gdb and attaching the PID of the
xorg process.

As long as gdb is attached to the process, and the -dbg package is installed,
xorg does not crash. Otherwise, it crashes every time. Not all the test cases
are affected. The 67 tests that run before this one, run fine.

If it does crash, it takes the ssh process with it, so I can't see the gdb
output.
Comment 1 jffry 2017-08-08 10:10:17 UTC
This has been forwarded from Debian:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857620
Comment 2 Ilia Mirkin 2017-08-08 11:34:55 UTC
What leads you to believe this is nouveau-related?
Comment 3 jffry 2017-08-08 11:38:07 UTC
Well, as Xorg is crashing, the problem must be either Xorg itself, or one of its modules.

The tests run fine on other machines with other (Xorg) graphics drivers, therefore I assume that the problem is nouveau.
Comment 4 Ilia Mirkin 2017-08-10 02:11:07 UTC
Works for me...

$ DISPLAY=:1 PERL5LIB="blib:lib:$PERL5LIB" perl t/114_cancel_save_pdf.t 
1..1
test.jpg JPEG 70x46 70x46+0+0 8-bit sRGB 2649B 0.000u 0:00.000
ok 1 - can create a valid JPG after cancelling save PDF process

Where DISPLAY=:1 is running on a G92 GPU.

Xorg 1.19.3 + xf86-video-nouveau 1.0.15
Comment 5 jffry 2017-08-10 17:37:30 UTC
The other two that crash X for me are:

t/124_cancel_save_djvu.t

t/252_cancel_negate.t

Do you have things still set up to try those, too?
Comment 6 Ilia Mirkin 2017-08-10 17:44:34 UTC
Well, my guess is there's something more going on. What GPU do you have? I can try running on a GK208 GPU as well (just wasn't easy to do immediately since that's my main one, but I can start a second X session separately).

[Yes, it's relatively easy for me to test, but not this second.]
Comment 7 jffry 2017-08-10 17:53:52 UTC
X.Org X Server 1.19.3
Module nouveau: vendor="X.Org Foundation"
[    18.179]    compiled for 1.19.3, module version = 1.0.15

NOUVEAU(0): Chipset: "NVIDIA NVC1"
nouveau 0000:01:00.0: NVIDIA GF108

I'd be happy to do some more debugging if you can help me get some useful information out of the crash.

Unfortunately, as I said before, as long as gdb is attached to the process, and the -dbg package is installed, xorg does not crash.
Comment 8 Ilia Mirkin 2017-08-13 16:41:19 UTC
I was unable to reproduce with GK208 as well. I'm not particularly inclined to believe that this is a nouveau issue, but ... you never know.

I'd recommend killing X, ssh'ing in from another machine, running X (and *only* X), e.g. "Xorg :0", and then, from another shell, running the affected application (setting DISPLAY=:0). If that triggers the crash, you can try that same setup with gdb and/or valgrind.
Comment 9 jffry 2017-08-13 21:36:37 UTC
I use lightdm. I booted the machine, but didn't log in.

I logged in from another machine via ssh:

$ ps -efl | grep org
4 S root      7814   570  0  80   0 - 96782 -      22:24 tty7     00:00:00 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

ssh had evidently started X, although I didn't use -X or -Y.

$ export DISPLAY=:0
$ PERL5LIB="blib:blib/arch:lib:$PERL5LIB" perl t/124_cancel_save_djvu.t 
1..1
Invalid MIT-MAGIC-COOKIE-1 keyGtk-WARNING **: cannot open display: :0 at /usr/lib/x86_64-linux-gnu/perl5/5.26/Gtk2.pm line 126.

$ Xorg :0
/usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server

$ sudo Xorg :0
(EE) 
Fatal server error:
(EE) Server is already active for display 0
	If this server is no longer running, remove /tmp/.X0-lock
	and start again.
(EE) 
(EE) 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
(EE) 

When I tried to log in with ssh -Y, the Perl test crashed and took out the ssh connection. $DISPLAY was set to localhost:10, which I assume means that nouveau is not the culprit.

How do I start the machine and not start X? Do I just kill X with -9, before starting it again. Isn't that what I had at the first attempt? If so, why could I not connect to it?
Comment 10 Ilia Mirkin 2017-08-13 21:55:33 UTC
(In reply to jffry from comment #9)
> How do I start the machine and not start X? Do I just kill X with -9, before
> starting it again. Isn't that what I had at the first attempt? If so, why
> could I not connect to it?

Sorry, I don't do distro support. Back in the bad old days, you could figure out what happened by looking at inittab, and modify rc.M or whatever.

You can start on :1 instead of :0 if you want to keep the existing one running, just make sure to switch to that VT on the machine.
Comment 11 jffry 2017-08-14 20:51:38 UTC
I ssh'ed in, started Xorg with sudo Xorg :1, ssh'ed in a second time, set DISPLAY, and ran the test.

Both ssh sessions died, and when I went back in, I saw that Xorg was still running on :1

So now I am confused. The Xorg logs show no errors.

What else can I check?
Comment 12 Martin Peres 2019-12-04 09:30:12 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/361.


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.