[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

[Christian Boos]

Follow-up Comment #3, bug #40226 (project make):

Well, the symptom can even be reproduced without a Makefile...


$ /C/Workspace/src/git/make/WinDebug/make -Otarget -f no-Makefile
make: no-Makefile: No such file or directory
make: *** internal error: multiple --sync-mutex options.  Stop.


The reason for this "multiple --sync-mutex options" problem
can be traced to the memory handling bug I presented earlier.
I'll try to explain better what I saw while I was debugging
this issue.

The initial allocation of the sync_mutex stringlist which 
happens in `prepare_mutex_handle_string ()` (main.c) leads
to the following memory layout at the address pointed to
by `sync_mutex->list`:


   +--------+
 0 |    x--------.
   +--------+    |
 1 |        |    |
   +--------+    |
 2 | "0xf4" |<---'
   +--------+


i.e. the blocks returned by the xmalloc and xstrdup
calls happen to be contiguous... So far, so good.

For reasons I didn't bother to check, the program then
enters `decode_switches ()` and one of these
switches is now "--sync-mutex 0xf4" (for example).
When handling this parameter in the `case string:`,
the code first tries to check if the stringlist
is not already allocated (it is), or if the list needs
to be expanded (*that check is wrong*). Here we have
idx == max == 1 for that list, so the expansion check
will wrongly decide all is fine and proceed with the
update code, which will make slot 1 point to "0xf4" 
and *null-terminate the list in the slot 2*.


   +--------+
 0 |    x--------.
   +--------+    |
 1 |    x-----------.
   +--------+    |  |
 2 |      0 |<---'  |
   +--------+       v
                  "0xf4" (somewhere else in memory)


Now we have the slot 0 pointing to an empty value
(`(char*)0) and slot 1 pointing to "0xf4", and this
is what `decode_output_sync_flags ()` detects and
reports as an error.

Hope my previous comments now make better sense ;-)

(please ignore the first patch file #29339 which was 
wrong; I believe the second patch file #29345 is correct,
as well as the alternative solution presented in comment #2
of changing the test operator from == to >=, in the expansion
check).




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?40226>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/