http://bugs.winehq.org/show_bug.cgi?id=24524
Summary: Cannot disable the debugger Product: Wine Version: unspecified Platform: x86 OS/Version: Mac OS X 10.6 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: kernel32 AssignedTo: wine-bugs@winehq.org ReportedBy: rgovostes@gmail.com
According to kernel32/except.c, there are only two behaviors supported by Wine:
1) (with AeDebug\Auto = 0) show a dialog when a crash occurs
2) (with AeDebug\Auto = 1) run a debugger process
There doesn't seem to be a way to have the program terminate on a crash. I suppose a program could override it by changing the exception handler but the default start_debugger() handler has this functionality.
http://bugs.winehq.org/show_bug.cgi?id=24524
rgovostes@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rgovostes@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=24524
Eric Pouech eric.pouech@orange.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |eric.pouech@orange.fr Ever Confirmed|0 |1
--- Comment #1 from Eric Pouech eric.pouech@orange.fr 2010-09-26 05:04:39 CDT --- actually, windows doesn't try to start a debugger if the AeDebug key is not present (wine always force the debugger here, and that should be changed) A+
http://bugs.winehq.org/show_bug.cgi?id=24524
--- Comment #2 from Alexandre Julliard julliard@winehq.org 2010-09-26 16:43:14 CDT --- You can set an empty value for AeDebug\Debugger, or use some non-existing program.
http://bugs.winehq.org/show_bug.cgi?id=24524
--- Comment #3 from rgovostes@gmail.com 2010-09-26 16:45:42 CDT --- (In reply to comment #2)
You can set an empty value for AeDebug\Debugger, or use some non-existing program.
No, that doesn't work. It errors trying to execute a nonexistent file, but it still sits waiting for a debugger to attach. I want the program to terminate as any other would, as is the natural order of things.
Yes, I could write a "debugger" which just terminates the attached process, but this is a pain to work around untypical behavior. I don't care what the defaults are, I just want to be able to make programs in Wine work like others.
http://bugs.winehq.org/show_bug.cgi?id=24524
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|rgovostes@gmail.com |
--- Comment #4 from Dmitry Timoshkov dmitry@codeweavers.com 2010-09-27 04:03:57 CDT --- Please specify the Wine version you are using (in the Version field above).
http://bugs.winehq.org/show_bug.cgi?id=24524
rgovostes@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.2
http://bugs.winehq.org/show_bug.cgi?id=24524
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #5 from Jörg Höhle hoehle@users.sourceforge.net 2010-10-25 09:22:54 CDT --- Somehow it's no surprise to me that the wish for disabling the debugger comes up on MacOS. I have observed cases where Wine behaved like a fork bomb: after a crash, launching winedbg crashed, causing another instance of winedbg to be started, crashing again ... I believe Wine should include some protection against recursively starting the debugger. I don't know why, but I've seen this every now and then on MacOS but at most once on Linux, so it's not only a MacOS issue.
IIRC, fork bombs occur when one of the two %ld values passed to --auto contain garbage (cause of garbage unknown) or point to unusable/protected memory.
IMHO, if winedbg would manage to produce backtraces and then exit on MacOS as reliably as it mostly does on Linux, the wish for disabling the debugger might not emerge.
http://bugs.winehq.org/show_bug.cgi?id=24524
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Mac OS X 10.6 |Mac OS X
http://bugs.winehq.org/show_bug.cgi?id=24524
--- Comment #6 from Austin English austinenglish@gmail.com 2013-11-13 16:52:34 CST --- This is your friendly reminder that there has been no bug activity for 2 years. Is this still an issue in current (1.7.6 or newer) wine? If so, please attach the terminal output in 1.7.6 (see http://wiki.winehq.org/FAQ#get_log).
https://bugs.winehq.org/show_bug.cgi?id=24524
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net Summary|Cannot disable the debugger |Add ability to disable the | |default JIT crash | |handler/debugger | |('AeDebug')
--- Comment #7 from Anastasius Focht focht@gmx.net --- Hello Austin,
probably yes, but I see little value for this "feature".
I do occasionally replace Wine's default JIT debugger 'winedbg' with 'OllyDbg' which is perfectly fine and works. Completely disabling the JIT crash handling is basically saying you don't care for crashes/diagnosis at all.
Does MacOS still suffer from this "mysterious" winedbg fork bombing?
Regards
https://bugs.winehq.org/show_bug.cgi?id=24524
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |ABANDONED
--- Comment #8 from Austin English austinenglish@gmail.com --- (In reply to Austin English from comment #6)
This is your friendly reminder that there has been no bug activity for 2 years. Is this still an issue in current (1.7.6 or newer) wine? If so, please attach the terminal output in 1.7.6 (see http://wiki.winehq.org/FAQ#get_log).
Abandoned.
https://bugs.winehq.org/show_bug.cgi?id=24524
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Austin English austinenglish@gmail.com --- Closing.