[bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

Follow-up Comment #8, bug #64806 (project make):

Is the brechtsanders build a 32-bit executable or a 64-bit executable?  If
it's a 64-bit executable, maybe the problem only rears its ugly head in a
64-bit build, because the ezwinports stuff is 32-bit.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64806] "invalid output sync mutex" on windows

[Michael Davidsaver]

Follow-up Comment #7, bug #64806 (project make):


> This bug report lacks a reproduction recipe ...

The closest which I think I can come to providing such a recipe is in WINE
where "-Otarget -j" works with the ezwinports build, but not with the
brechtsanders/winlibs_mingw build.

detailed outputs included with:

https://github.com/brechtsanders/winlibs_mingw/issues/174#issuecomment-1793823524

I have asked brechtsanders for more details on this build process and
environment.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64806] "invalid output sync mutex" on windows

[Michael Davidsaver]

Follow-up Comment #6, bug #64806 (project make):


> This bug report lacks a reproduction recipe ...

Yes, I know.  Unfortunately (well, in this instance ;) ) I run Linux
exclusively on my personal systems and only interact with windows via
continuous integration builds.  Troubleshooting with CI is ... tedious.  If I
could reproduce this issue from a local build, I would likely be submitting a
patch instead of this confused investigation into where these two windows
builds originate.  (this whole process reminds me not to take "apt-get source
make" for granted)

> ... it is not clear whether the make.exe binary which exhibits the problem
is the one from ezwinports or something else ...

I observed this issue with the make.exe distributed with the Strawberry Perl
5.38.0.1 installer.  From what I have found, this binary originates as a
"personal build" by Brecht Sanders (see comment #2).  So as far as I can tell,
this binary is _not_ from ezwinports.

> So more information is needed to make any progress with this bug report.

As explained above, there are limits to what additional information I can
provide.

I made a brief test on Linux to rename /usr/bin/make to something longer or
shorter.  Both appear to work, and running with valgrind does not report any
errors.

This makes me wonder whether src/getopt.c is involved?

>From what I can tell from src/main.c, it looks like the pointer stored in
argv[0] is being saved prior to calling getopt_long().  Of course, there is a
lot of #ifdef in that file, which makes it difficult for me to follow.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64806] "invalid output sync mutex" on windows

[Michael Davidsaver]

Follow-up Comment #5, bug #64806 (project make):

Quoting @shawnlaffan from
https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/148#issuecomment-1783929512

> The root cause of the issue seems to be that the make executables do not
support recursive calls when they have been renamed. Calling as mingw32-make
will work in this case, but not make and I suspect also not gmake. ...

In combination with the variation in error messages which I see, I suspect an
use-after-free of argv[0] or a copy of the same.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/