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

[Greg Chicares]

On 2020-05-15 17:57, Vadim Zeitlin wrote:
> 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> Segmentation fault
> GC> make: [GNUmakefile:467: check_concinnity] Error 139 (ignored)
> GC> 
> GC> OTOH, it works (no segfault) with gcc-8.3 .

I awoke from my nap thinking that the cause might be something other
than gcc--maybe instead it's wine, for example. The difference between
the two environments is really just the date: both are debian-testing
chroots, but one was created yesterday and the other hasn't been
updated in about six months.

>  Should I try to debug this

Sure, if you really want, but I think it's a matter of exceeding
the command-line limit (of 'wine', probably), and the segfault
or signal 11 I'm seeing indicates nothing more than that.

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

That's the crucial insight. See commit 76666492:
    This command line
      x.c y.c z.c ...
    is shorter than
      /opt/lmi/src/lmi/x.c /opt/lmi/src/lmi/y.c /opt/lmi/src/lmi/z.c ...
    so
      cd some/dir/ && foo *
    may be short enough where
      foo some/dir/*
    exceeds a command-line limit.

-       @-$(PERFORM) $(TEST_CODING_RULES) $(prefascicle_dir)/*
+       @-cd $(prefascicle_dir) && $(PERFORM) $(TEST_CODING_RULES) *

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

Exactly. That's the answer. Thanks.