re: FYI: new X server in -current, among other X things

[matthew green <mrg%eterna.com.au@localhost>]

Robert Swindells writes:
> 
> I wrote:
> >
> >>> [   378.033] (EE) 0: /usr/X11R7/bin/X (xorg_backtrace+0x44) [0x1467d46d5]
> >>> [   378.033] (EE) 1: /usr/X11R7/bin/X (os_move_fd+0x79) [0x1467d0465]
> >>> [   378.033] (EE) 2: /usr/lib/libc.so.12 (__sigtramp_siginfo_2+0x0) [0x75b46379c930]
> >>> [   378.034] (EE) 
> >>> [   378.034] (EE) Segmentation fault at address 0x0
> >>> 
> >>> This happens with ctwm as part of the base installation, as well as with
> >>> other pre-existing window managers and such from pkgsrc built against
> >>> 9.99.97.
> >>
> >>can you configure X to generate a core dump or run it
> >>under GDB and get the real stack trace?  i thought we'd
> >>fixed this problem in libexecinfo, but it's still not
> >>tracing through the SEGV above, so finding what is
> >>crashing where is what we need next.
> >
> >FWIW, I get the same on my Pinebook with a lima kernel, this may not be
> >i915 specific.
> >
> >Doing a full debug build now.
>
> Building with MKDEBUG=yes stops it crashing, but it also stops glamor
> from working.
>
> I guess it is back to printf().

with a normal build, you should at least be able to get
a stack trace with function names, if not line numbers.

you'll have to disable the xorg SEGV catcher... oh they
seem to have removed that entirely:

commit c7414f4d07b69a4b2f0d0af06f032393cf5fe6aa
Author: Adam Jackson <ajax%redhat.com@localhost>   
Date:   Wed Aug 22 14:57:05 2018 -0400 

    xfree86: Remove NoTrapSignals 
	
    This was dangerous on UMS and largely pointless on KMS.


have you tried running the (non-debug) one from inside
gdb as well, that should also give you something.


.mrg.