Bug 102106

This has been forwarded from Debian:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857620

What leads you to believe this is nouveau-related?

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.

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

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?

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.]

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.

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.

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?

(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.

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?

-- 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.