[bug #63157] Unlink temporary files.

2022-10-20 Thread Martin Dorey
Follow-up Comment #26, bug #63157 (project make): Ach, it did reproduce for me, with or without Dmitry's modification. I was just looking in the wrong place, despite Frank providing copy-and-paste instructions on where to look. Perhaps I'd just read about MAKE_TMPDIR and assumed that they'd end

[bug #63157] Unlink temporary files.

2022-10-20 Thread Dmitry Goncharov
Follow-up Comment #25, bug #63157 (project make): This may not always reproduce, because there is a race between make writing its output to the pipe and the reader exiting. Sigpipe is sent when the reader exits before make is able to write its output. However, if you change it like this echo

[bug #63157] Unlink temporary files.

2022-10-19 Thread Frank Heckenbach
Follow-up Comment #24, bug #63157 (project make): [comment #23 comment #23:] > Frank wrote [ > > I now found a way to reproduce it quite easily on my system. > As I suspected, it seems to be SIGPIPE: > > % rm -f /tmp/G* > % cat Makefile > all: ; sleep 1 > % make -j2 -O 2>&1 | : > % ls -l

[bug #63157] Unlink temporary files.

2022-10-19 Thread Martin Dorey
Follow-up Comment #23, bug #63157 (project make): Frank wrote [ I now found a way to reproduce it quite easily on my system. As I suspected, it seems to be SIGPIPE: % rm -f /tmp/G* % cat Makefile all: ; sleep 1 % make -j2 -O 2>&1 | : % ls -l /tmp/G* prw--- 1 frank frank 0 19. Okt 22:42

Re: [bug #63157] Unlink temporary files.

2022-10-19 Thread Frank Heckenbach
Paul D. Smith wrote: > Follow-up Comment #21, bug #63157 (project make): > > The only places leftover files may happen is (a) on Windows, only when (b) you > kill GNU make with ^C or similar. > > Any other leftover files should not happen. Please provide details of the > names of the files

[bug #63157] Unlink temporary files.

2022-10-19 Thread Dmitry Goncharov
Follow-up Comment #22, bug #63157 (project make): Frank, can you please tell us how to reproduce? ___ Reply to this item at: ___ Message sent via

[bug #63157] Unlink temporary files.

2022-10-19 Thread Paul D. Smith
Follow-up Comment #21, bug #63157 (project make): The only places leftover files may happen is (a) on Windows, only when (b) you kill GNU make with ^C or similar. Any other leftover files should not happen. Please provide details of the names of the files that are left over and which

[bug #63157] Unlink temporary files.

2022-10-18 Thread Frank Heckenbach
Follow-up Comment #20, bug #63157 (project make): Unfortunately, I still get leftover temp files and fifos with 4.3.91. If I understand you right, it's not worth investigating it further now, is it? Just one guess: Since I pipe make's output to my tools, that might be the cause. So you might

[bug #63157] Unlink temporary files.

2022-10-18 Thread Paul D. Smith
Update of bug #63157 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #63157] Unlink temporary files.

2022-10-15 Thread Paul D. Smith
Follow-up Comment #19, bug #63157 (project make): It's probably not worth spending a lot of time ruminating on these things. The reality is that currently make does many non-handler-safe things in its signal handler, and there are Savannah bugs about hangs etc. while catching SIGINT which prove

[bug #63157] Unlink temporary files.

2022-10-15 Thread Frank Heckenbach
Follow-up Comment #18, bug #63157 (project make): [comment #17 comment #17:] > Paul, if you decide to proceed with changes in comment 11, temp_stdin_fileno should probably be of type volatile sig_atomic_t, rather than int. Are you sure that's big enough? According to

[bug #63157] Unlink temporary files.

2022-10-14 Thread Dmitry Goncharov
Follow-up Comment #17, bug #63157 (project make): i think, it is fine (maybe even good) if the changes in comment 11 are abandoned. The whole critical section only lasts while make is reading and parsing the temp stdin file. The duration of this critical section is likely to be a fraction of

[bug #63157] Unlink temporary files.

2022-10-12 Thread Paul D. Smith
Follow-up Comment #16, bug #63157 (project make): Sorry I should have been more clear. When I said "non-regression changes" I was specifically referring to the extra effort needed to get files to be deleted on Windows, as in comment #11 That change is related to the temporary stdin file, not to

[bug #63157] Unlink temporary files.

2022-10-12 Thread Frank Heckenbach
Follow-up Comment #15, bug #63157 (project make): FWIW, I do consider this a regression, since these things weren't even created before. Now, after some weeks of trying make 4.3.90, I get a number of empty files and named pipes lying around -- probably from aborted make runs, but such is life

[bug #63157] Unlink temporary files.

2022-10-06 Thread Paul D. Smith
Follow-up Comment #14, bug #63157 (project make): Thanks, I will look at this within the next few days. Note, I'm not too concerned with non-regression changes for signal handling: the fact is that our current signal handling is totally broken (see the 5-6 issues related to things not dying

[bug #63157] Unlink temporary files.

2022-10-05 Thread Dmitry Goncharov
Follow-up Comment #13, bug #63157 (project make): Thank you, Eli. ___ Reply to this item at: ___ Message sent via Savannah https://savannah.gnu.org/

[bug #63157] Unlink temporary files.

2022-10-05 Thread Eli Zaretskii
Follow-up Comment #12, bug #63157 (project make): Thanks, the diffs look good (although I didn't actually test them). ___ Reply to this item at: ___

[bug #63157] Unlink temporary files.

2022-10-05 Thread Dmitry Goncharov
Follow-up Comment #11, bug #63157 (project make): > If temp_stdin is fclosed, then there's no need to call close on its fileno. Right. We have to take care of the critical section between fopen and fclose. The reasoning is the following. 1. The patch works on unices. 2. On windows the patch

[bug #63157] Unlink temporary files.

2022-10-05 Thread Eli Zaretskii
Follow-up Comment #10, bug #63157 (project make): If temp_stdin is fclosed, then there's no need to call close on its fileno. I don't think I follow your reasoning. Could you tell more details, including pointers to the source code? What do you mean by "We won't be able to use fclose, which is

[bug #63157] Unlink temporary files.

2022-10-05 Thread Dmitry Goncharov
Follow-up Comment #7, bug #63157 (project make): close is async signal safe and we call close before unlink. Should make also calls close before unlink in all other places where make unlinks this (or any other) file? ___ Reply to this

[bug #63157] Unlink temporary files.

2022-10-05 Thread Dmitry Goncharov
Follow-up Comment #9, bug #63157 (project make): In the case of temp_stdin eval_makefile fcloses this file. We'll need to store temp_stdin_fileno in a file scope variable (next to stdin_offset) and pass it to close in temp_stdin_unlink. We won't be able to use fclose, which is okay, since make is

[bug #63157] Unlink temporary files.

2022-10-05 Thread Eli Zaretskii
Follow-up Comment #6, bug #63157 (project make): > If the file is opened at the time of unlink, only file's name is removed from the directory and the file itself stays. When make exits the last reference to the file is gone and the file is deleted. That's what happens on Unix. On Windows, the

[bug #63157] Unlink temporary files.

2022-10-05 Thread Dmitry Goncharov
Follow-up Comment #8, bug #63157 (project make): we *can* call close before unlink ___ Reply to this item at: ___ Message sent via Savannah

[bug #63157] Unlink temporary files.

2022-10-05 Thread Dmitry Goncharov
Follow-up Comment #5, bug #63157 (project make): > This should be tested on MS-Windows. A file can only be deleted on MS-Windows if it isn't open by any program, and the patch (AFAICT) doesn't make sure the files are closed before unlinking them. I'm especially worried about the

[bug #63157] Unlink temporary files.

2022-10-05 Thread Eli Zaretskii
Follow-up Comment #4, bug #63157 (project make): This should be tested on MS-Windows. A file can only be deleted on MS-Windows if it isn't open by any program, and the patch (AFAICT) doesn't make sure the files are closed before unlinking them. I'm especially worried about the temp_stdin_unlink

[bug #63157] Unlink temporary files.

2022-10-04 Thread Dmitry Goncharov
Follow-up Comment #3, bug #63157 (project make): Also, tested presence of PPID variable in ksh, bash, ash, zsh, sh. The only shell that i encountered that lacks PPID is tcsh (likely csh as well). The test uses the default shell. This means that test will likely fail on a system where /bin/sh is

[bug #63157] Unlink temporary files.

2022-10-04 Thread Dmitry Goncharov
Follow-up Comment #2, bug #63157 (project make): Tested this patch on linux, sun and aix. All 64 bit. This patch adds jobserver_unlink stub on windows. As far as i can visually validate, this stub should compile fine. However, have not tested this on windows.

[bug #63157] Unlink temporary files.

2022-10-04 Thread Dmitry Goncharov
Additional Item Attachment, bug #63157 (project make): File name: sv63157_fix.diff Size:4 KB File name: sv63157_test.diff Size:2 KB

[bug #63157] Unlink temporary files.

2022-10-04 Thread Dmitry Goncharov
Follow-up Comment #1, bug #63157 (project make): Make fails to unlink temporary files upon arrival of a fatal signal. Specifically, the jobserver fifo, output sync lock and the stdin temp file. ___ Reply to this item at:

[bug #63157] Unlink temporary files.

2022-10-04 Thread Dmitry Goncharov
URL: Summary: Unlink temporary files. Project: make Submitter: dgoncharov Submitted: Wed 05 Oct 2022 02:24:38 AM UTC Severity: 3 - Normal Item Group: Bug