Created attachment 133819 [details]
X.org.0.log (DRI disabled)

An other xorg log with DRI disabled

Created attachment 133820 [details]
lspci-vv

Created attachment 133821 [details]
lspci-nn

Created attachment 133822 [details]
dmesg


I triggered the segfault between these two log lines:

[  914.124797] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:54:VGA-1] disconnected
[ 1978.446104] [drm:drm_mode_addfb2 [drm]] [FB:65]

Created attachment 133823 [details]
dmesg with arandr OK

And if I use arandr (right click -> resolution -> 1368x768), the scaling is done without a segfault. 

Which also explain why I didn't notice the segfault before (I tend to use xrandr when debuging display problem, which is quite rare, and arandr / desktop change resolution tool for my day to day use).

The bt is not that useful without the symbols, and that --scale explodes is quite, quite surprising. If you can get a clean bt, try recompiling with --enable-debug and make sure the symbols aren't stripped on install that will be a big help.

I'm a little lost, I'm not succeding to have the trace with debug symbol. 

I compiled xf86-video-intel with "-O -g -ffast-math -march=native -ggdb3" and addede "--enable-debug" to configure. 
I took care (ok, it was the third time before I succeed) to not let arch mkpkg strip the debug symbols. The resulting /usr/lib/xorg/modules/drivers/intel_drv.so is 15M, so it seems to have what is needed, but I still get the non informative stack. 

Is there something else that I have to do to get the nice bt?

(I know I can do it, I also recompiled xorg-server and mesa for that other segfault:https://phab.enlightenment.org/T5957, it was a fabulous evening. Now I now that mesa is a very big package with debug symbol, I believe it can be accounted as a win ?)

It's the first time I'm trying to do these things, perhaps I'm missing something obvious?

Hmm, that sounds like it should have been able to pick up the symbols. The last resort is to use "sudo gdb --pid ($pidof Xorg)" from a remote login.

To check that it picked up the recompiled intel_drv.so, after --enable-debug you should get ""SNA compiled with assertions enabled" in the Xorg.log. If that is in order, and we still don't have a good stacktrace, use --enable-debug=full and attach the compressed Xorg.log and I'll figure out where it dies based on the last debug message.

Just an idea - where should I use / set "--enable-debug" ? Because perhaps I'm just not doing it right. Is it a config option of "./configure", or a parameter of xorg starting command, or something else?

(sorry if it sounds very dumb)

It's an option to ./configure (or ./autogen.sh) of xf86-video-intel.

So, I did the correct thing and I had the "SNA compiled with assertions enabled". 

So here goes the full debug log. 
What I did (if it helps understanding):

- in console, restart lightdm; 
- switch to console 7, log-in in lightdm
- enlightenment starts
- open a terminal, enter: "xrandr -s 800x600", enter 

=> segfault, lightdm restarts. 

Switch back to console 1, copy/compress X.org.log.old. 

Hope it helps. 

Don't hesitate to ask, if you need some other piece of xorg recompiled with the debug symbole, I'm starting to be good at that :) (ok, modulo the critical fails here)

Created attachment 133876 [details]
Xorg.0.log for xf86-video-intel-git 1:2.99.917+781+gc8990575-1 with --enable-debug=full

Comment on attachment 133876 [details]
Xorg.0.log for xf86-video-intel-git 1:2.99.917+781+gc8990575-1 with --enable-debug=full

xf86-video-intel-git 1:2.99.917+781+gc8990575-1 with --enable-debug=full

Ah, can you tweak the assert

diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index d1f01218..3f70d536 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -565,7 +565,7 @@ static void assert_scanout(struct kgem *kgem, struct kgem_bo *bo,
        assert(drmIoctl(kgem->fd, DRM_IOCTL_MODE_GETFB, &info) == 0);
        gem_close(kgem->fd, info.handle);
 
-       assert(width == info.width && height == info.height);
+       assert(width <= info.width && height <= info.height);
 }
 #else
 #define assert_scanout(k, b, w, h)

and try again?

Yep, that worked :) 

Congrats !

Uhoh, that will have only fixed up an assert that you could not have hit before we started testing...

That's really funny :) OK, I will try to reproduce - but I can't with the previous method, so I need to understand what changed (perhaps I was just using a debug package all along, which is not totally to exclude since 1/ as you said, a bug in scala is highly unlikely and 2/ I was trying to debug other things https://phab.enlightenment.org/T5941 https://phab.enlightenment.org/T5957)

Thanks for the help in all cases !

-- 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-intel/issues/148.