[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET
From: |
Christian Boos |
Subject: |
[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET |
Date: |
Sun, 13 Oct 2013 18:57:56 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.16 Safari/537.36 |
Follow-up Comment #9, bug #40226 (project make):
Eli, it looks like the problem is triggered as soon
as you have some output generated during the
`read_all_makefiles ()` phase, as it causes a call
to `prepare_mutex_handle_string ()`.
And after reading the Makefiles, `main ()` calls
`decode_env_switches ("MAKEFLAGS")` which in turn
calls `decode_switches ()` and the added flag
`--sync-mutex=0x44` is now present.
So in my example at the top of comment #3, the trigger
was the `perror_with_name ()` call for the missing
no-Makefile file.
The problem indeed doesn't happen with simple
Makefiles where make doesn't generate any output
while reading the Makefiles.
Examples:
$ cat Makefile.bug
$(info Hello)
all:
@echo All done
$ WinDebug/make.exe -f Makefile.bug -Otarget
Hello
make: *** internal error: multiple --sync-mutex options. Stop.
$ cat Makefile.ok
all:
$(info Hello)
@echo All done
$ WinDebug/make.exe -f Makefile.ok -Otarget
Hello
All done
Of course, you have to be "lucky" and have that particular
memory layout I described in comment #3, i.e. the initial
xstrdup in `prepare_mutex_handle_string ()` must allocate
the "0x44" string just after the list itself. Otherwise
the memory overwrite that happens in `decode_switches ()`
is likely to remain asymptomatic. For example, when I launch
make from the debugger, the allocation pattern is different
and all seems fine, I could only figure this out by
attaching the debugger to the process...
Also, I just noticed that the problem is only reproducible
with 64-bits builds. I figure it might be difficult to
reproduce with other builds of make (msys, cygwin).
So the bug is likely to remain unnoticed most of the time,
which doesn't mean it's not there ;-)
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?40226>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET, anonymous, 2013/10/09
- [bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET, Christian Boos, 2013/10/10
- [bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET, Eli Zaretskii, 2013/10/12
- [bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET, Christian Boos, 2013/10/13
- [bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET, Paul D. Smith, 2013/10/13
- [bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET, Eli Zaretskii, 2013/10/13
- [bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET, Paul D. Smith, 2013/10/13
- [bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET, Eli Zaretskii, 2013/10/13
- [bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET, Eli Zaretskii, 2013/10/13
- [bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET,
Christian Boos <=
- [bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET, Christian Boos, 2013/10/14