http://bugs.winehq.org/show_bug.cgi?id=14789
Chris chris.kcat@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chris.kcat@gmail.com
--- Comment #5 from Chris chris.kcat@gmail.com 2008-08-07 23:15:23 ---
Second - that is a pure debug function that is not even used by default - one have to recompile wineserver with #define DEBUG_OBJECTS 1. And then send -HUP to the server.
Just because it's only used in the debug path doesn't make it's use any less invalid. If anything it'll make debugging harder as this can trip and hide the real problem being tracked.
Third it's called from the signal handler which guarantees it won't ever reenter.
So I don't see what reentrancy are you talking about here?
Reentrancy is when a function is called while another context/frame is also inside the function. This can very much happen in a single-threaded app. Take for example:
1> User code runs 2> User code enters fprintf 3> Signal interrupt (user code is paused inside fprintf) 4> Signal handler enters fprintf (!!both user code and signal handler are inside fprintf!!) 5> Signal handler leaves fprintf 6> Signal handler exits and resumes user code 7> User code continues inside fprintf 8> User code leaves fprintf
IMO, this is a valid bug. You should not be using fprintf inside a signal handler because it's not gauranteed to handle this situation.