| delorie.com/archives/browse.cgi | search |
| DMARC-Filter: | OpenDMARC Filter v1.4.2 delorie.com 5AC9Ovkb2151159 |
| Authentication-Results: | delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com |
| Authentication-Results: | delorie.com; spf=pass smtp.mailfrom=cygwin.com |
| DKIM-Filter: | OpenDKIM Filter v2.11.0 delorie.com 5AC9Ovkb2151159 |
| Authentication-Results: | delorie.com; |
| dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=l5MIYlSq | |
| X-Recipient: | archive-cygwin AT delorie DOT com |
| DKIM-Filter: | OpenDKIM Filter v2.11.0 sourceware.org 5A7E93858409 |
| DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; |
| s=default; t=1762939495; | |
| bh=1E4MJqwzj/1BM073ewt5oJ30b0lc98Oeoc4/6wsSljo=; | |
| h=Date:To:Cc:Subject:In-Reply-To:References:List-Id: | |
| List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: | |
| From:Reply-To:From; | |
| b=l5MIYlSqBBh+ZSLll6B9vsRtgE7D1Am5Q0Srf3EP43UAq7/SoB/1q1oGzAQ/M53X5 | |
| cQua9FWe+VkQ7w4EdjPKIQIS6Y10Yg4KOccACasYPTommqVV1VPgVYMMWA5tL3LS3J | |
| vnPqhzR2MzF/oUKvKTskgJFKN0P7YBz94tyNIanU= | |
| X-Original-To: | cygwin AT cygwin DOT com |
| Delivered-To: | cygwin AT cygwin DOT com |
| DMARC-Filter: | OpenDMARC Filter v1.4.2 sourceware.org 05BE93858C50 |
| ARC-Filter: | OpenARC Filter v1.0.0 sourceware.org 05BE93858C50 |
| ARC-Seal: | i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1762939456; cv=none; |
| b=qNRaLoAXe/BWDHVieqwEoEzsxZWjzm55zu8ucUjFIFT0qF5x0rFtVSL/OYORMUhmmHl+qumh9BZcfo/26ZrKOB7Epcyh4FwLRDHzsMLJTTY57tLBzKl/eogA9vsVtRJ3kJ+L09fkYJEIbFsY+TWrnH7ImW5Kl+zd9qWqx5+uuxs= | |
| ARC-Message-Signature: | i=1; a=rsa-sha256; d=sourceware.org; s=key; |
| t=1762939456; c=relaxed/simple; | |
| bh=M42zCXjd7yWkRphvxPIeGhA01/hhf01sN/EhcnmNe3o=; | |
| h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature; | |
| b=JH2YojAickdxeAFQuQ4gwH8kx9bdLcXo2G3kQTdxAbDyHrPSMlYusKVBfFoVkx+XtfWqd6x363ixcLjMHJwWYHB+mImNSQWQBNJj7rZnHs99IS7HoNYlJlKzyALB4KJ4Xw8jArUBbhW5lpXuZ7wOap4wp3HPqNQSXPWakzS26Dg= | |
| ARC-Authentication-Results: | i=1; server2.sourceware.org |
| DKIM-Filter: | OpenDKIM Filter v2.11.0 sourceware.org 05BE93858C50 |
| Date: | Wed, 12 Nov 2025 18:24:12 +0900 |
| To: | cygwin AT cygwin DOT com |
| Cc: | Nahor <nahor.j+cygwin AT gmail DOT com> |
| Subject: | Re: flock/open random error |
| Message-Id: | <20251112182412.ba3a65f36838b9b5fd7d3f9b@nifty.ne.jp> |
| In-Reply-To: | <CA+1R0VjcBajGpLMJ_0Waie0g_5S15_kPfzpT2=GUyN+39RWrMw@mail.gmail.com> |
| References: | <CA+1R0VjcBajGpLMJ_0Waie0g_5S15_kPfzpT2=GUyN+39RWrMw AT mail DOT gmail DOT com> |
| X-Mailer: | Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) |
| Mime-Version: | 1.0 |
| X-BeenThere: | cygwin AT cygwin DOT com |
| X-Mailman-Version: | 2.1.30 |
| List-Id: | General Cygwin discussions and problem reports <cygwin.cygwin.com> |
| List-Unsubscribe: | <https://cygwin.com/mailman/options/cygwin>, |
| <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe> | |
| List-Archive: | <https://cygwin.com/pipermail/cygwin/> |
| List-Post: | <mailto:cygwin AT cygwin DOT com> |
| List-Help: | <mailto:cygwin-request AT cygwin DOT com?subject=help> |
| List-Subscribe: | <https://cygwin.com/mailman/listinfo/cygwin>, |
| <mailto:cygwin-request AT cygwin DOT com?subject=subscribe> | |
| From: | Takashi Yano via Cygwin <cygwin AT cygwin DOT com> |
| Reply-To: | Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp> |
| Errors-To: | cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com |
| Sender: | "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com> |
On Tue, 21 Oct 2025 17:41:51 -0700
Nahor wrote:
> Hi,
>
> There is a test in the Fish shell (tests::history::test_history_races)
> that systematically fails when I run it. The test simulates multiple
> processes/threads trying to write to the shell history file at the
> same time.
> In my case, the test freezes/deadlocks with errors like "Bad Addr" and
> "Is Directory".
> When I add a sleep, the freeze/deadlocks disappear but the test
> eventually fails because the fake history is not the right size.
> See https://github.com/fish-shell/fish-shell/issues/11933 for more details.
>
> I wrote a test case in pure C (attached) that also triggers the issue
> although it's not as systematic (30-50%).
> To compile: gcc main.c -o test.exe
> To run: ./test.exe
>
>
> Most failures look like this:
> ```
> $ ./test.exe
> tmp_dir: /tmp/flockc2Hz4c
> open file error: 21 - Is a directory
> /tmp/flockc2Hz4c/append_file
> assertion "file_fd >= 0" failed: file "main.c", line 49, function:
> thread_func
> Aborted
> ```
> Occasionally (maybe 10%), it looks like that:
> ```
> $ ./test.exe
> tmp_dir: /tmp/flock5Oly9J
> lock error: 14 - Bad address
> assertion "lock_res == 0" failed: file "main.c", line 38,
> function: thread_func
> Aborted
> ```
>
> I believe the freeze/deadlock in the Fish test is because, unlike my
> test, they don't assert/crash, and the next time they access the
> history file, there is a bunch of deadlock in cygwin internals.
> If that helps, this is a partial capture of the stack traces at one such time:
> ```
> Thread 9
> #2 0x00000001800d487f in muto::acquire (this=0x1802c24c0
> <lock_process::locker>, ms=ms AT entry=4294967295) at
> /d/S/B/src/msys2-runtime/winsup/cygwin/sync.cc:84
> #3 0x00000001800dd6e0 in dtable::lock (this=<optimized out>) at
> /d/S/B/src/msys2-runtime/winsup/cygwin/local_includes/dtable.h:77
> #4 cygheap_fdnew::cygheap_fdnew (this=<synthetic pointer>,
> seed_fd=-1, lockit=true) at
> /d/S/B/src/msys2-runtime/winsup/cygwin/local_includes/cygheap.h:593
> #5 open (unix_path=0xa0002b3b0
> "[...]/fish-shell/target/fish-test-home", flags=262144) at
> /d/S/B/src/msys2-runtime/winsup/cygwin/syscalls.cc:1576
>
> Thread 10
> #2 0x00000001800d487f in muto::acquire (this=0x1802c24c0
> <lock_process::locker>, ms=ms AT entry=4294967295) at
> /d/S/B/src/msys2-runtime/winsup/cygwin/sync.cc:84
> #3 0x00000001800dd6e0 in dtable::lock (this=<optimized out>) at
> /d/S/B/src/msys2-runtime/winsup/cygwin/local_includes/dtable.h:77
> #4 cygheap_fdnew::cygheap_fdnew (this=<synthetic pointer>,
> seed_fd=-1, lockit=true) at
> /d/S/B/src/msys2-runtime/winsup/cygwin/local_includes/cygheap.h:593
> #5 open (unix_path=0xa0002bfe0
> "[...]/fish-shell/target/fish-test-home/race_test_history.FwyAgK",
> flags=264706) at
> /d/S/B/src/msys2-runtime/winsup/cygwin/syscalls.cc:1576
>
> Thread 11
> #2 0x00000001800670bb in inode_t::LOCK (this=0x80000ba20) at
> /d/S/B/src/msys2-runtime/winsup/cygwin/flock.cc:314
> #3 inode_t::get (dev=1881899537, ino=ino AT entry=10977524092162599,
> create_if_missing=create_if_missing AT entry=false, lock=lock AT entry=true)
> at /d/S/B/src/msys2-runtime/winsup/cygwin/flock.cc:504
> #4 0x0000000180068eb1 in fhandler_base::del_my_locks
> (this=0x80000b810, from=on_close) at
> /d/S/B/src/msys2-runtime/winsup/cygwin/flock.cc:402
> #5 0x000000018010d5bf in fhandler_base::close_with_arch
> (this=0x80000b810, flag=flag AT entry=-1) at
> /d/S/B/src/msys2-runtime/winsup/cygwin/fhandler/base.cc:1306
> #6 0x00000001800de36b in __close (fd=5, flag=-1) at
> /d/S/B/src/msys2-runtime/winsup/cygwin/syscalls.cc:1710
> #7 close (fd=5) at /d/S/B/src/msys2-runtime/winsup/cygwin/syscalls.cc:1722
>
> Thread 12
> #2 0x00000001800d487f in muto::acquire (this=0x1802c24c0
> <lock_process::locker>, ms=ms AT entry=4294967295) at
> /d/S/B/src/msys2-runtime/winsup/cygwin/sync.cc:84
> #3 0x00000001800dd6e0 in dtable::lock (this=<optimized out>) at
> /d/S/B/src/msys2-runtime/winsup/cygwin/local_includes/dtable.h:77
> #4 cygheap_fdnew::cygheap_fdnew (this=<synthetic pointer>,
> seed_fd=-1, lockit=true) at
> /d/S/B/src/msys2-runtime/winsup/cygwin/local_includes/cygheap.h:593
> #5 open (unix_path=0x7ff10b488
> "[...]/fish-shell/target/fish-test-home/race_test_history.pZO5DS",
> flags=263169) at
> /d/S/B/src/msys2-runtime/winsup/cygwin/syscalls.cc:1576
> ```
> The freeze/deadlock can be reproduced in my C code by calling
> "continue" inside the "if (lock_res != 0) {" instead of triggering the
> assert just after.
>
>
> I haven't been able to reproduce the missing data in the history file
> so it's unknown if it's an issue in Fish or flock not locking properly
> at times. So far the test passes on Linux and MacOS.
Thanks for the report.
Do you have any evidence that flock() should be MT-safe?
This issue seems to be caused by the fact that flock() in
cygwin is not MT-safe.
If flock is guarded by mutex in your test case, the issue
does not happen.
--
Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |