Re: xsrc/55853: [dM] xdpyinfo sometimes loses output

[mlelstv%serpens.de@localhost (Michael van Elst)]

The following reply was made to PR xsrc/55853; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: xsrc/55853: [dM] xdpyinfo sometimes loses output
Date: Wed, 9 Dec 2020 05:11:24 -0000 (UTC)

 mouse%Rodents-Montreal.ORG@localhost (Mouse) writes:
 
 >	Under certain circumstances, xdpyinfo unexpectedly produces no
 >	output.  My impression of the circumstances is "stdout isn't a
 >	tty", but that's just a guess.
 
 xdypinfo | wc
     1892    7775   65536
 
 gives a magic number of output bytes.
 
 A ktrace gives
 
   6636      1 xdpyinfo CALL  write(1,0x7b37a000,0x4000)
   6636      1 xdpyinfo RET   write 16384/0x4000
   6636      1 xdpyinfo CALL  write(1,0x7b37a000,0x4000)
   6636      1 xdpyinfo RET   write 16384/0x4000
   6636      1 xdpyinfo CALL  write(1,0x7b37a000,0x4000)
   6636      1 xdpyinfo RET   write 16384/0x4000
   6636      1 xdpyinfo CALL  write(1,0x7b37a000,0x4000)
   6636      1 xdpyinfo RET   write 16384/0x4000
 
 But with tty output, it is line buffered and all writes sum up to
 67874 bytes.
 
 So the last buffered output isn't flushed. Depending on your
 xdpyinfo generated output, this might be everything.
 
 You also see in the trace that xdpyinfo exits with code 3 in
 either case.
 
 Breakpoint 1, 0x7bb89394 in _exit () from /usr/lib/libc.so.12
 (gdb) where
 #0  0x7bb89394 in _exit () from /usr/lib/libc.so.12
 #1  0x7bde3af8 in XF86cleanup (sig=<optimized out>) at /home/netbsd9/xsrc/external/mit/libXxf86dga/dist/src/XF86DGA.c:660
 #2  0x7bed2574 in _rtld_call_function_void (obj=0x7befbc00, addr=2078161548) at /home/netbsd9/src/libexec/ld.elf_so/rtld.h:490
 #3  _rtld_call_initfini_function (obj=0x7befbc00, mask=<optimized out>, func=2078161548) at /home/netbsd9/src/libexec/ld.elf_so/rtld.c:143
 #4  _rtld_call_fini_function (cur_objgen=<optimized out>, mask=<optimized out>, obj=0x7befbc00) at /home/netbsd9/src/libexec/ld.elf_so/rtld.c:173
 #5  _rtld_call_fini_functions (mask=mask@entry=0x7fffd510, force=force@entry=1) at /home/netbsd9/src/libexec/ld.elf_so/rtld.c:204
 #6  0x7bed34bc in _rtld_exit () at /home/netbsd9/src/libexec/ld.elf_so/rtld.c:418
 #7  0x7bb5f778 in __cxa_finalize (dso=dso@entry=0x0) at /home/netbsd9/src/lib/libc/stdlib/atexit.c:222
 #8  0x7bb5f378 in exit (status=0) at /home/netbsd9/src/lib/libc/stdlib/exit.c:60
 #9  0x000149a8 in main (argc=<optimized out>, argv=<optimized out>) at /home/netbsd9/xsrc/external/mit/xdpyinfo/dist/xdpyinfo.c:1506
 
 
 static void
 #ifdef __NetBSD__
 __attribute__ ((__destructor__))
 #endif
 XF86cleanup(int sig)  
 {
     ScrPtr sp;
     int i;
     static char beenhere = 0;
 
     if (beenhere)
         _exit(3);
     beenhere = 1;
 
     for (i = 0; i < numScrs; i++) {
         sp = scrList[i];
         XF86DGADirectVideo(sp->display, sp->screen, 0);
         XSync(sp->display, False); 
     }
     _exit(3);
 }
 
 That code is usually called by an atexit() handler or by a fatal
 signal handler which are set up in XF86DGAGetVideo.
 
 But we cannot run an atexit handler in a possibly dlopen'ed
 shared library safely, so we have patched libXxf86dga (and others)
 to run atexit handlers unconditionally as a library destructor.
 
 In either case that code doesn't make sense as you get the _exit(3)
 also on other systems once XF86DGAGetVideo() has been called and
 the atexit handler is installed. But with our change to a destructor,
 the bug is always there.
 
 xdpyinfo links against libXxf86dga because it queries the XF86DGA
 extension and calls XF86DGAGetVideoLL for information. It doesn't
 call XF86DGAGetVideo. Other systems, using the upstream code,
 therefore do not see that issue.
 
 
 -- 
 -- 
                                 Michael van Elst
 Internet: mlelstv%serpens.de@localhost
                                 "A potential Snark may lurk in every tree."