[Bug 14789] Fix signal handler

wine-bugs at winehq.org wine-bugs at winehq.org
Thu Aug 7 23:15:23 CDT 2008


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.

More information about the wine-bugs mailing list