[Bug 14789] Fix signal handler

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=14789


Chris <chris.kcat at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chris.kcat at gmail.com




--- Comment #5 from Chris <chris.kcat at 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.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.