Re: Segmentation Fault on Exported Resursively Expanded Variable

[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, *ep can be no shorter than having \0 at position nl and
>>> accessing that position should not cause any segfault.

On Tue, 16 Jan 2024 20:53:19 +0200
Eli Zaretskii  wrote:
>> But it's less efficient when the (*ep)[nl] == '=' test fails.

Henrik Carlqvist (17 January 2024 07:24) wrote:
> Yes, that is true, but to avoid a possible segfault it is necessary to
> somehow check that (*ep)[nl] is a valid address. The current fix at
> https://savannah.gnu.org/bugs/index.php?65172 also works fine, but
> also that fix might be even less efficient as strlen will read every
> char up to and including \0 in *ep.

or, to look at it another way, you can't legally access (*ep)[nl] until
you've looked at every (*ep)[i] for 0 <= i < nl, since if any of those
is '\0' then the memory segment you're allowed to access might end
before (*ep)[nl], making it an invalid memory access.

Henrik's proposed fix Does The Right Thing and is cleaner than the
current proposed fix,

Eddy.

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

[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 sometimes does
work, right?  So it isn't that inheriting mutex handles doesn't work in
general, it's more like sometimes the handle is "taken" after the child
process called osync_clear (which frees the handle for opening any other file
object), and then the handle is no longer usable as a mutex, and a grandchild
process inherits that unusable handle.

So perhaps only the top-level make, the one which calls CreateMutex, should
call CloseHandle on the mutex?  Can you try that?




___

Reply to this item at:

  

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

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

[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 Process Explorer indicates that 0x128 in a grandchild process
(18728) that is waiting is not a mutex, but "\Device\ConDrv" (see attached
screenshot).  Surprisingly, if one hits ENTER in the terminal window of "hung"
processes, their execution resumes.  At this point I suspected that when we
think that we are waiting for the mutex in osync_acquire(), in reality we are
waiting for the standard input (which would explain the phenomenon that
hitting ENTER resumes execution).  Added instrumentation that logs in separate
files calls to CreateMutex(), WaitForSingleObject() and CloseHandle() in
w32os.c and CloseHandle() and CreateProcess() in sub_proc.c.  Let the root
process be of PID 2728, its child 7116, grandchild 18728 as shown in the
attached screenshot.  According to the log, the following happens (log entries
are in the form "[PID] FILE:FUNCTION: logged API call", only relevant lines
and only from processes 2728, 7116 and 18728 kept, lines were originally
timestamped and ordered, timestamps are hidden for readability):

[2728]  w32os.c:osync_setup: CreateMutex(): 0x128 <<< 2728 creates
mutex with handle 0x128
[...]
[2728]  sub_proc.c:process_begin: CreateProcess: 7116 <<< 2728 creates
process 7116 that inherits
  <<< handle 0x128
referring to the mutex
[...]
[7116]  w32os.c:osync_acquire: WaitForSingleObject(0x128) <<< 7116 uses the
mutex via handle 0x128
[...]
[7116]  w32os.c:osync_acquire: WaitForSingleObject(0x128) <<< 7116 still uses
the mutex via handle 0x128
[...]
[7116]  w32os.c:osync_clear: CloseHandle(0x128)   <<< 7116 closes
handle of the mutex
[...]
[7116]  sub_proc.c:process_begin: CreateProcess: 18728<<< 7116 creates
process 18728 that may inherit a handle
  <<< 0x128 but it is
not a mutex any more but probably
  <<< some terminal
stream, most probably obtained when
  <<< redirecting
stdin/out etc.
[...]
[18728] w32os.c:osync_acquire: WaitForSingleObject(0x128) <<< 18728 tries to
wait for the "mutex" but in reality
  <<< it is waiting
for something else resulting in hang

As indicated in the comments above, if I am not mistaken, the grandchild
process 18728 did not inherit the mutex in handle 0x128 as intended, but 0x128
refers to something else, this seems to be the reason for the hang.

Commenting out the CloseHandle() call from in osync_clear() eliminates the
hang: the entire compilation goes fine, even output synchronization is OK. 
(Removing CloseHandle() is clearly undesired practice, but since Windows
should close any open handles when a process terminates, this temporary
workaround is probably not a long-term resource leak).

To put together: closing the mutex handle before creating a child process that
is expected to use that mutex by inheriting the handle, seems to be the root
cause of the phenomenon.  Maybe this is related to inclusion of dependency
files that had to be created by make.


(file #55583)

___

Additional Item Attachment:

File name: mingw32-make-procexp.png   Size:25 KB
   



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-d1e0f7a1b19199bb94f733b79bf92733e4fe5029.tar.gz


___

Reply to this item at:

  

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