Mikołaj Zalewski a écrit :
I've written a dialog about a crash some time ago to add to winedbg
(http://www.winehq.org/pipermail/wine-patches/2009-January/068073.html).
It's probably time to ask what is the status of this patch?
If this patch gets accepted (Alexandre seemed to like the previous
version, but pointed that it broke kernel32 tests because there had
been no way to disable it and he didn't have much time to review it),
maybe calling `winedbg --auto` from ReportFault would be the best way
- you would then have a dialog (the same as during a regular crash,
can be disabled from the registry), the full debugger output and an
option to run an interactive debugger. AFAIK this is the other way
round than Windows does (AFAIK drwatson loads faultrep.dll into the
process that crashed and calls ReportFault), but loading a DLL into a
process where everything could be corrupted seems a strange idea.
Jérôme Gardou pisze:
Most wine users, when their app crashes, open a bug report and attach
the console log. If the log contains information got from
ReportFault, developers will gain some time, and have the preceding
context of the call.
I'm affraid this is what is done by the 1% best users ;). I'd expect
that a typical user to complain that Linux is broken because on Linux,
from time to time, apps just disappear from the screen while on
Windows they don't. Already knowing that there is such a thing like
Wine requires some knowledge :).
Mikołaj Zalewski
Instead of reinventing the wheel, why not call kernel32 which does it
for us.... What do you think about this patch?
From 8d94c4a333f90cc2be6c9019f84ccc7712b5a0b2 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?J=C3=A9r=C3=B4me=20Gardou?= <jerome.gar...@laposte.net>
Date: Mon, 23 Feb 2009 09:35:13 +0100
Subject: [PATCH] faultrep: Make ReportFault do something useful
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------1.6.0.6"
This is a multi-part message in MIME format.
--------------1.6.0.6
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
---
dlls/faultrep/faultrep.c | 7 ++++++-
dlls/kernel32/except.c | 2 +-
dlls/kernel32/kernel32.spec | 3 +++
3 files changed, 10 insertions(+), 2 deletions(-)
--------------1.6.0.6
Content-Type: text/x-patch; name="8d94c4a333f90cc2be6c9019f84ccc7712b5a0b2.diff"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
filename="8d94c4a333f90cc2be6c9019f84ccc7712b5a0b2.diff"
diff --git a/dlls/faultrep/faultrep.c b/dlls/faultrep/faultrep.c
index d4bd713..bb896f9 100644
--- a/dlls/faultrep/faultrep.c
+++ b/dlls/faultrep/faultrep.c
@@ -37,6 +37,7 @@ static const WCHAR SZ_EXCLUSIONLIST_KEY[] = {
'E','r','r','o','r','R','e','p','o','r','t','i','n','g','\\',
'E','x','c','l','u','s','i','o','n','L','i','s','t', 0};
+
/*************************************************************************
* AddERExcludedApplicationW [faultr...@]
*
@@ -107,7 +108,11 @@ BOOL WINAPI AddERExcludedApplicationA(LPCSTR lpAppFileName)
*/
EFaultRepRetVal WINAPI ReportFault(LPEXCEPTION_POINTERS pep, DWORD dwOpt)
{
- FIXME("%p 0x%x stub\n", pep, dwOpt);
+ LONG ret ;
+ TRACE("%p 0x%x stub\n", pep, dwOpt);
+
+ ret = wine_start_debugger_atomic(pep) ;
+
return frrvOk;
}
diff --git a/dlls/kernel32/except.c b/dlls/kernel32/except.c
index 21d3584..f471e05 100644
--- a/dlls/kernel32/except.c
+++ b/dlls/kernel32/except.c
@@ -347,7 +347,7 @@ EXIT:
*
* returns TRUE for the two first conditions, FALSE for the last
*/
-static int start_debugger_atomic(PEXCEPTION_POINTERS epointers)
+int CDECL start_debugger_atomic(PEXCEPTION_POINTERS epointers)
{
static HANDLE hRunOnce /* = 0 */;
diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec
index b0f4ee7..e5e79c3 100644
--- a/dlls/kernel32/kernel32.spec
+++ b/dlls/kernel32/kernel32.spec
@@ -1264,3 +1264,6 @@
# Init code
@ cdecl __wine_kernel_init()
+
+#debugging
+@ cdecl wine_start_debugger_atomic(ptr) start_debugger_atomic
--------------1.6.0.6--
