Re: [lmi] 'wine test_coding_rules.exe' segfault

[Vadim Zeitlin]

On Fri, 15 May 2020 17:18:07 +0000 Greg Chicares <address@hidden> wrote:

GC> To reproduce: build lmi with gcc_i686-w64-mingw32 version 9.3, then:
GC> 
GC> /opt/lmi/src/lmi[0]$make check_concinnity                                   
                  
GC> make[1]: Entering directory '/opt/lmi/src/lmi'
GC> make[2]: 'test_coding_rules.exe' is up to date.
GC> make[1]: Leaving directory '/opt/lmi/src/lmi'
GC>   Problems detected by xmllint:
GC>   Miscellaneous problems:
GC> Segmentation fault
GC> make: [GNUmakefile:467: check_concinnity] Error 139 (ignored)
GC> 
GC> OTOH, it works (no segfault) with gcc-8.3 .
GC> 
GC> The line number "GNUmakefile:467" is inexact; the segfault really
GC> occurs a few lines later, on this line:
GC>     @-$(PERFORM) $(TEST_CODING_RULES) $(prefascicle_dir)/*
GC> and can be reproduced in isolation thus:
GC> 
GC> /opt/lmi/src/lmi[0]$wine 
/opt/lmi/gcc_i686-w64-mingw32/build/ship/test_coding_rules.exe 
/opt/lmi/src/lmi/*   
GC> zsh: segmentation fault  wine 
/opt/lmi/gcc_i686-w64-mingw32/build/ship/test_coding_rules.exe 

 Should I try to debug this and see if we can find some workaround, e.g.
maybe disable optimizations in some function or something like this, or do
you think it's a waste of time and we should rather work around the problem
using one of the solutions you found?

GC> Curiously, passing the '/*' expansion into xargs as a single
GC> undivided lump avoids the segfault:
GC> 
GC> /opt/lmi/src/lmi[0]$echo * | xargs wine /opt/lmi/bin/test_coding_rules.exe
GC>       658 source files
GC>    184005 source lines
GC>       346 marked defects

 I have no explanation for this... Does it work if you launch it with just
"*" on the command line, i.e. from /opt/lmi/src/lmi directory? Or,
conversely, does it still crash with "echo /opt/lmi/src/lmi/* | xargs"?
Maybe this has something to do with the command line length?

GC> but that fails with a subshell:
GC> 
GC> /opt/lmi/src/lmi[0]$dash -c find ./ -maxdepth 1 -type f -name '[!.]*' | 
xargs wine /opt/lmi/bin/test_coding_rules.exe
GC> xargs: wine: terminated by signal 11

 I don't understand this at all neither... The right side of the pipeline
is executed by the parent/current shell, so how could the fact that its
input comes from a subshell change anything at all??

GC> and none of those tricks suggests a 'GNUmakefile' change that actually
GC> works, perhaps because 'make' runs all commands through a shell.

 The first thing I'd try would be to cd to $(prefascicle_dir) first, just
in case this bug is related to the command line length. The second thing
would probably be to debug it myself, as I wrote above, because I don't
really have any other ideas right now.

GC> BTW, the argument list generated with 'find' is shorter than the
GC> expansion of '*':
GC> 
GC> /opt/lmi/src/lmi[0]$find . -maxdepth 1 -type f | wc
GC>     775     775   15590
GC> /opt/lmi/src/lmi[0]$echo * |wc                            
GC>       1     782   14079

 This is due to "*" including both files and directories, but excluding
files starting with dot. If you use "echo *(.) .*(.) | sed 's/ /\n/g'", you
will get exactly the same result as from "find ... | sed 's@^./@@'".

GC> Maybe the solution to this problem is to redesign 'test_coding_rules'
GC> to accept a directory argument, and distinguish it from a file list.

 This would be pretty simple to do, of course, but I don't really like not
understanding at all why does it crash.

GC> Vadim--any other ideas?

 Sorry, nothing really useful, yet, but if you think it's worth spending
time on this, I'd like to debug this and hopefully find something. Please
let me know if I should.

 Thanks,
VZ

pgpPcSVaXiKZG.pgp
Description: PGP signature