Re: Segmentation Fault on Exported Resursively Expanded Variable

2024-01-17 Thread Edward Welbourne
MIAOW Miao wrote: if ((*ep)[nl] == '=' && strncmp (*ep, v->name, nl) == 0) Henrik Carlqvist (Tue, 16 Jan 2024 06:59:30 +) wrote: >>> Looking at that line, the rather obvious fix would be to change it to: >>> >>> if (strncmp (*ep, v->name, nl) == 0 && (*ep)[nl] == '=') >>> >>> That way,

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

2024-01-17 Thread Eli Zaretskii
Follow-up Comment #28, bug#64806 (group make): Thanks, this is important information. So I think the next step is to understand which call to osync_clear closes the handle. Maybe we shouldn't make that call, at least on Windows? Also, this only happens sometimes, right? That is, -Otarget

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

2024-01-17 Thread Gergely Pinter
Follow-up Comment #27, bug#64806 (group make): I went on with analysis of the situation as follows. When processes are apparently hung, they are waiting for a handle whose numeric value equals the handle of the mutex created by the root process (0x128 in the example below). At this point