_sim_debug_flush(): Use fsync(). #454
Conversation
bscottm
force-pushed
the
debug_flush_loop
branch
from
7df5086 to
e6a4d44
Compare
|
I'm a bit confused here. You pointed out that the simulated fsync can't be used in multithreaded simh. So why is it still in the code? If it's broken, would it not be more logical to remove it, especially since everyone has fsync? |
It can still be used for single threaded code, i.e., simulators that don't use AIO. Also, I don't have a good handle on which platforms SIMH is supposed to support (the Very happy to take it out and rewrite code to assume everyone has |
bscottm
force-pushed
the
debug_flush_loop
branch
from
e6a4d44 to
2e6a571
Compare
@pkoning2: It's all just |
| * | ||
| * f == NULL: fwrite() returns 0 on Linux and Windows. len never gets decremented | ||
| * and an infinite loop ensues (cue "Forever NULL" sung to the tune of Alphaville's | ||
| * "Forever Young".) |
There was a problem hiding this comment.
Why not simply treat length written == 0 as an error? But in my testing, a NULL file pointer causes a segfault (on recent Linux as well as on Mac OS).
There was a problem hiding this comment.
@pkoning2: I left the "dragon" note as more of a "Don't Do This" warning. I added extra checks deal with the f == NULL,len_written == 0 and errno != EAGAIN cases. In each case, SIMH outputs a diagnostic message (the "why") and the buffer's contents that weren't written to the debug output.
bscottm
force-pushed
the
debug_flush_loop
branch
3 times, most recently
from
af23c88 to
072fe53
Compare
Fix race condition in _debug_fwrite_all() where the FILE *f output file can be permanently NULL, causing fwrite() to permanently return zero and resulting in an infinite loop on mulithreaded SIMH. This pathology primarily occurs when main thread calls flush_svc() and one of the Ethernet threads (reader, writer) emits debugging output. Linux and macOS platforms invoke fsync() to synchronize file data to disk. Windows has a fsync() wrapper calling _commit() providing the same semantics. Issue traced to _sim_debug_flush() calling sim_set_deboff(0, NULL) to simulate fsync().
bscottm
force-pushed
the
debug_flush_loop
branch
from
072fe53 to
43407a0
Compare
2 participants
Fix race condition in _debug_fwrite_all() where the FILE *f output file can be permanently NULL, causing fwrite() to permanently return zero and resulting in an infinite loop on mulithreaded SIMH. This pathology primarily occurs when main thread calls flush_svc() and one of the Ethernet threads (reader, writer) emits debugging output.
Linux, macOS invoke fsync(). Windows invokes a fsync() wrapper that invokes _commit().
Issue traced to _sim_debug_flush() calling sim_set_deboff(0, NULL) to simulate fsync().