diff options
| author | Bitflash <btf01@proton.me> | 2026-07-29 12:46:33 -0300 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2026-07-29 12:46:33 -0300 |
| commit | 6e836ed5cb5f41391e335b4f508dc6c0e8915ba5 (patch) | |
| tree | 77d9175f60192242bbca4ad43b3ae44c7eb827a5 /src/gui.cpp | |
| parent | 1227068a504418521f3238acf9c4dca297141d27 (diff) | |
util: stop debug.log dropping lines under concurrency (#29)
OutputDebugStringF resolved its path lazily with no lock:
static string strDebugFile;
if (strDebugFile.empty()) { ... strDebugFile = dir + "\\" + "debug.log"; }
FILE* fileout = fopen(strDebugFile.c_str(), "a");
if (fileout) { ... }
One thread could read that string while another was still assigning to it, and
at startup three threads log within milliseconds of each other. When it raced,
fopen received a torn path, returned NULL, and the `if (fileout)` dropped the
line with no error anywhere. Several threads calling fopen on the same file at
once had no protection either.
Measured over six runs, counting first-statement printfs that are unconditional
and must appear every time:
ThreadBtfAccept started 4/6
ThreadNostrSeed started 5/6
btfpeers: (cached peers) 2/6
Over eight runs after the change, all three are 8/8.
This matters beyond tidiness. A missing line was read as a thread that never
started, and a real investigation was spent on it. Any reasoning of the form
"it is not in the log, so it did not happen" was unsound against this build.
Path resolution and the write now share one critical section. The rest of the
function already had its own for the OutputDebugString accumulation path; only
the file half was unguarded.
Diffstat (limited to 'src/gui.cpp')
0 files changed, 0 insertions, 0 deletions