Closed Bug 54792 Opened 24 years ago Closed 23 years ago

nsDebug::Assertion does not prevent re-entry into the main window

Categories

(Core :: XPCOM, defect, P3)

Product:
Core
Component:
XPCOM
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jrgmorrison, Assigned: jband_mozilla)

References

(
URL
)

Details

Attachments

(3 files)

a patch to WrappedNative_Finalize to force the problem
842 bytes, patch
Details | Diff | Splinter Review
diff for nsDebug.cpp to launch windbgdlg.exe
2.54 KB, patch
Details | Diff | Splinter Review
two new files (attached as one file) for xpcom\windbgdlg
3.58 KB, text/plain
Details 
(Note: brendan asked me to file this bug, but any bogosities in the
 explanation are, of course, mine.)

Overview Description:
  nsDebug::Assertion does not prevent re-entry into the main window
event loop. It was suggested that it should.

  In bug , you could hit a crash in a debug build, when closing the
  X control on the View Source window. What appears to happen is that
  an assertion MessageBox would be popped up, and then the windowproc
  would be reentered, leading to a crash on a JS_ASSERT. The visible
  result would be that you had two dialog boxes up on the screen, and
  a very strange looking stack (see below).

  If you run the same set of user actions while the debugger is up
  (and you don't use the MessageBox call in nsDebug::Assertion), then
  you simply get three assertions from GlobalWindowImpl, and no crash
  in the JS GC code.

  Not sure who to give this to, but trying dougt, cc: danm

Steps to Reproduce:
1) In a current debug build on win32, start the browser.
2) do View->Source.
3) Click on the X close control for the ViewSource window.

Reproducibility: 100%

Build Date & Platform Bug Found: mozilla trunk build pulled 2am 09/29


NTDLL! 77f9f9df()
js_AllocGCThing(JSContext * 0x0295ea18, unsigned int 0) line 381 + 41 bytes
js_NewObject(JSContext * 0x0295ea18, JSClass * 0x011a8ca8 struct JSClass
KeyEventClass, JSObject * 0x00d22a08, JSObject * 0x00000000) line 1440 + 11 bytes
JS_NewObject(JSContext * 0x0295ea18, JSClass * 0x011a8ca8 struct JSClass
KeyEventClass, JSObject * 0x00d22a08, JSObject * 0x00000000) line 1892 + 21 bytes
NS_NewScriptKeyEvent(nsIScriptContext * 0x028fe990, nsISupports * 0x03c609ac,
nsISupports * 0x00000000, void * * 0x0012c218) line 1014 + 23 bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x03c609ac) line 141 + 25 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x02a6eff0,
nsIDOMEvent * 0x03c609ac, nsIDOMEventTarget * 0x02a6ed30, unsigned int 16,
unsigned int 2) line 788 + 19 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x049f3278, nsEvent *
0x0012d530, nsIDOMEvent * * 0x0012d46c, nsIDOMEventTarget * 0x02a6ed30, unsigned
int 2, nsEventStatus * 0x0012d574) line 935 + 39 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x02a6ed28, nsIPresContext *
0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2,
nsEventStatus * 0x0012d574) line 3321
nsXULElement::HandleChromeEvent(nsXULElement * const 0x02a6ed3c, nsIPresContext
* 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2,
nsEventStatus * 0x0012d574) line 4296 + 39 bytes
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x0326f9a8,
nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c,
unsigned int 2, nsEventStatus * 0x0012d574) line 520
nsDocument::HandleDOMEvent(nsDocument * const 0x04b28130, nsIPresContext *
0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2,
nsEventStatus * 0x0012d574) line 3054
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x049f3278, nsEvent *
0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus *
0x0012d574) line 1433 + 45 bytes
nsHTMLHtmlElement::HandleDOMEvent(nsHTMLHtmlElement * const 0x03ecfdc0,
nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c,
unsigned int 2, nsEventStatus * 0x0012d574) line 186
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x049f3278, nsEvent *
0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus *
0x0012d574) line 1426 + 45 bytes
nsHTMLBodyElement::HandleDOMEvent(nsHTMLBodyElement * const 0x032735f0,
nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c,
unsigned int 2, nsEventStatus * 0x0012d574) line 902
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x049f3278, nsEvent *
0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus *
0x0012d574) line 1426 + 45 bytes
nsHTMLTableElement::HandleDOMEvent(nsHTMLTableElement * const 0x03285660,
nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c,
unsigned int 2, nsEventStatus * 0x0012d574) line 1345
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x049f3278, nsEvent *
0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus *
0x0012d574) line 1426 + 45 bytes
nsHTMLTableSectionElement::HandleDOMEvent(nsHTMLTableSectionElement * const
0x03269080, nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * *
0x0012d46c, unsigned int 2, nsEventStatus * 0x0012d574) line 355
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x049f3278, nsEvent *
0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 2, nsEventStatus *
0x0012d574) line 1426 + 45 bytes
nsHTMLTableRowElement::HandleDOMEvent(nsHTMLTableRowElement * const 0x03280650,
nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * * 0x0012d46c,
unsigned int 2, nsEventStatus * 0x0012d574) line 713
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x049f3278, nsEvent *
0x0012d530, nsIDOMEvent * * 0x0012d46c, unsigned int 1, nsEventStatus *
0x0012d574) line 1426 + 45 bytes
nsHTMLTableCellElement::HandleDOMEvent(nsHTMLTableCellElement * const
0x0482fb74, nsIPresContext * 0x049f3278, nsEvent * 0x0012d530, nsIDOMEvent * *
0x00000000, unsigned int 1, nsEventStatus * 0x0012d574) line 525
nsEventStateManager::GenerateMouseEnterExit(nsIPresContext * 0x049f3278,
nsGUIEvent * 0x0012dcb0) line 1519
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x047b5400,
nsIPresContext * 0x049f3278, nsEvent * 0x0012dcb0, nsIFrame * 0x049032f4,
nsEventStatus * 0x0012dba0, nsIView * 0x04924628) line 306
PresShell::HandleEventInternal(nsEvent * 0x0012dcb0, nsIView * 0x04924628,
unsigned int 1, nsEventStatus * 0x0012dba0) line 4249 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x03db64c4, nsIView * 0x04924628,
nsGUIEvent * 0x0012dcb0, nsEventStatus * 0x0012dba0, int 0, int & 1) line 4190 +
25 bytes
nsView::HandleEvent(nsView * const 0x04924628, nsGUIEvent * 0x0012dcb0, unsigned
int 8, nsEventStatus * 0x0012dba0, int 0, int & 1) line 379
nsView::HandleEvent(nsView * const 0x0490fe70, nsGUIEvent * 0x0012dcb0, unsigned
int 8, nsEventStatus * 0x0012dba0, int 0, int & 1) line 352
nsView::HandleEvent(nsView * const 0x0318e140, nsGUIEvent * 0x0012dcb0, unsigned
int 28, nsEventStatus * 0x0012dba0, int 1, int & 1) line 352
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x04581158, nsGUIEvent *
0x0012dcb0, nsEventStatus * 0x0012dba0) line 1439
HandleEvent(nsGUIEvent * 0x0012dcb0) line 68
nsWindow::DispatchEvent(nsWindow * const 0x04924004, nsGUIEvent * 0x0012dcb0,
nsEventStatus & nsEventStatus_eIgnore) line 681 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012dcb0) line 702
nsWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line 3890 +
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line 4100
nsWindow::ProcessMessage(unsigned int 512, unsigned int 0, long 1114776, long *
0x0012e02c) line 2937 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x00280104, unsigned int 512, unsigned int 0, long
1114776) line 950 + 27 bytes
USER32! 77e13eb0()
USER32! 77e1401a()
USER32! 77e13f0f()
USER32! 77e23570()
USER32! 77e32e3e()
USER32! 77e32891()
USER32! 77e333c6()
USER32! 77e38d45()
USER32! 77e38cd2()
nsDebug::Assertion(const char * 0x0119f324, const char * 0x0119f314, const char
* 0x0119f2e0, int 4053) line 215 + 22 bytes
nsDebug::WarnIfFalse(const char * 0x0119f324, const char * 0x0119f314, const
char * 0x0119f2e0, int 4053) line 358 + 21 bytes
GlobalWindowImpl::GetTreeOwner(GlobalWindowImpl * const 0x035230b8,
nsIDocShellTreeOwner * * 0x0012ef3c) line 4053 + 38 bytes
GlobalWindowImpl::Get_content(GlobalWindowImpl * const 0x035230bc,
nsIDOMWindowInternal * * 0x0012ef5c) line 701 + 40 bytes
nsBrowserInstance::ReinitializeContentVariables() line 475 + 42 bytes
nsBrowserInstance::GetContentAreaDocShell(nsIDocShell * * 0x0012eff8) line 497
nsBrowserInstance::Close(nsBrowserInstance * const 0x03d9db60) line 1496 + 32 bytes
nsBrowserInstance::~nsBrowserInstance() line 460
nsBrowserInstance::`scalar deleting destructor'() + 15 bytes
nsBrowserInstance::Release(nsBrowserInstance * const 0x03d9db60) line 563 + 158
bytes
nsXPCWrappedNative::~nsXPCWrappedNative() line 398 + 27 bytes
nsXPCWrappedNative::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsXPCWrappedNative::Release(nsXPCWrappedNative * const 0x03d9dbe8) line 71 + 31
bytes
nsXPCWrappedNative::JSObjectFinalized(JSContext * 0x03621ce8, JSObject *
0x03b8e7c0) line 96
WrappedNative_Finalize(JSContext * 0x03621ce8, JSObject * 0x03b8e7c0) line 783
js_FinalizeObject(JSContext * 0x03621ce8, JSObject * 0x03b8e7c0) line 1600 + 114
bytes
gc_finalize_phase(JSContext * 0x03621ce8, unsigned int 115) line 907 + 11 bytes
js_GC(JSContext * 0x03621ce8, unsigned int 0) line 1173 + 13 bytes
js_ForceGC(JSContext * 0x03621ce8) line 871 + 11 bytes
js_DestroyContext(JSContext * 0x03621ce8, int 2) line 219 + 9 bytes
JS_DestroyContext(JSContext * 0x03621ce8) line 832 + 11 bytes
nsJSContext::~nsJSContext() line 366 + 13 bytes
nsJSContext::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsJSContext::Release(nsJSContext * const 0x03bd7178) line 374 + 154 bytes
nsCOMPtr<nsIScriptContext>::assign_assuming_AddRef(nsIScriptContext *
0x00000000) line 472
nsCOMPtr<nsIScriptContext>::assign_with_AddRef(nsISupports * 0x00000000) line 849
nsCOMPtr<nsIScriptContext>::operator=(nsIScriptContext * 0x00000000) line 584
nsDocShell::Destroy(nsDocShell * const 0x034f745c) line 1614
nsWebShell::Destroy(nsWebShell * const 0x034f745c) line 1394
nsXULWindow::Destroy(nsXULWindow * const 0x03b30e4c) line 324
nsWebShellWindow::Destroy(nsWebShellWindow * const 0x03b30e4c) line 1779
nsWebShellWindow::Close(nsWebShellWindow * const 0x03b30ea8) line 368
nsWebShellWindow::HandleEvent(nsGUIEvent * 0x0012f51c) line 447
nsWindow::DispatchEvent(nsWindow * const 0x034f860c, nsGUIEvent * 0x0012f51c,
nsEventStatus & nsEventStatus_eIgnore) line 681 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f51c) line 702
nsWindow::DispatchStandardEvent(unsigned int 101) line 722 + 15 bytes
nsWindow::ProcessMessage(unsigned int 16, unsigned int 0, long 0, long *
0x0012f854) line 2795
nsWindow::WindowProc(HWND__ * 0x002a00fa, unsigned int 16, unsigned int 0, long
0) line 950 + 27 bytes
USER32! 77e13eb0()
USER32! 77e1591b()
USER32! 77e1595d()
NTDLL! 77f9fb83()
USER32! 77e169a7()
USER32! 77e13eb0()
USER32! 77e16469()
USER32! 77e1a6f8()
nsWindow::WindowProc(HWND__ * 0x002a00fa, unsigned int 274, unsigned int 61536,
long 1508213) line 957 + 31 bytes
USER32! 77e13eb0()
USER32! 77e1591b()
USER32! 77e1595d()
NTDLL! 77f9fb83()
USER32! 77e169a7()
USER32! 77e13eb0()
USER32! 77e16469()
USER32! 77e1a6f8()
nsWindow::WindowProc(HWND__ * 0x002a00fa, unsigned int 161, unsigned int 20,
long 1508213) line 957 + 31 bytes
USER32! 77e13eb0()
USER32! 77e1401a()
USER32! 77e192da()
nsAppShellService::Run(nsAppShellService * const 0x00b729b8) line 408
main1(int 1, char * * 0x00496e50, nsISupports * 0x00000000) line 1004 + 32 bytes
main(int 1, char * * 0x00496e50) line 1185 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e87903()
Er, sorry. Meant to include the bug number where this condition was originally
noted -- bug 53953.

*** Bug 54981 has been marked as a duplicate of this bug. ***
*** Bug 55040 has been marked as a duplicate of this bug. ***
*** Bug 55198 has been marked as a duplicate of this bug. ***
*** Bug 56952 has been marked as a duplicate of this bug. ***
Lotta dups, which means wasted time (yes, mine too, which makes me grumpy).  Is 
there an easy fix to the MessageBox call?

/be
When I first ran into this I tried fiddling with the MessageBox flags (e.g. 
MB_SYSTEMMODAL) with no luck. Amybe something I didn't try will work?

The reason this call exists at all in our code is to allow people to 
choose 'ignore' on asserts without having to start up the debugger. I think this 
was bogus from the start. We should be more forceful in removing misplaced 
asserts rather than tolerating them. Commenting out the code that makes this 
messagebox come up and then jumping on any asserts that can be safely bypassed 
seems like the thing to do AFAIC.
Dammit, now I remember this!  Travis!!!

Yes, we've wasted enough time, both on dups of this bug, and on tolerating bogus 
assertions.  Is this really all that MessageBox is for?  What happens on other 
platforms?

/be
  I tried several of the bugs which are marked duplicates of this one; none crash 
for me. The view source crash in particular I fixed, and it had nothing to do 
with Windows system alerts. The crash was already well on its way before any 
alert was spawned.
  John, do you have an easy way to make this crash happen? I was talking about 
this with Brendan last week. Although I'm not so sure now, I remember thinking 
the problem would be because the system modal alert launched into its own event 
loop which knew nothing of the stacked event queues in our home-spun modal 
dialogs; the stacked queues which prevent nspr event processing in earlier 
windows.
  If this is still a problem (I gather it is) I'd like to see it happen so I can 
be sure about that. We'll need to rip out system alerts or hack something into 
the debug assertion code that has a similar effect as stacked queues. Or 
something altogether different if it's from far left field you hear my voice.

danm: the JS_GC must not be running when js_AllocGCThing runs, and won't be if 
finalizers are well-written, and provided we fix this stupid MessageBox bug.  I 
see no need to drag the event queue service into this.  It's purely a matter of 
bad control flow that normally "can't happen".

/be
I attached a patch that can be used to force this problem to occur. you can 
change the value of FREQUENCY to hit different code paths. In my trunk build 
from today the setting of '100' in this patch will cause the crash without the 
dialog yet becoming visible (but in its msg loop no doubt). A value of 50 
(in my build) will cause the app to abort at this point with no oportunity at 
all to start the debugger!
Alright. With John's assertion randomizer patch, I get crashes that look like 
this

(crash)
js_AllocGCThing(JSContext * 0x00cea2a8, unsigned int 0) line 420 + 41 bytes
js_NewObject(JSContext * 0x00cea2a8, JSClass * 0x0030d410 _js_FunctionClass, 
JSObject * 0x00000000, JSObject * 0x03154c80) line 1442 + 11 bytes
js_NewFunction(JSContext * 0x00cea2a8, JSObject * 0x00000000, int (JSContext *, 
JSObject *, unsigned int, long *, long *)* 0x00000000, unsigned int 1, unsigned 
int 0, JSObject * 0x03154c80, JSAtom * 0x03428ae8) line 1629 + 20 bytes
...
nsWindow::ProcessMessage(unsigned int 8, unsigned int 1900810, long 0, long * 
0x0012e170) line 3112 + 19 bytes
nsWindow::WindowProc(HWND__ * 0x00090210, unsigned int 8, unsigned int 1900810, 
long 0) line 958 + 27 bytes
...
nsDebug::Assertion(const char * 0x013066c4, const char * 0x013066b0, const char * 
0x01306668, int 776) line 215 + 22 bytes
WrappedNative_Finalize(JSContext * 0x03406b08, JSObject * 0x0345ddb0) line 776 + 
58 bytes
js_FinalizeObject(JSContext * 0x03406b08, JSObject * 0x0345ddb0) line 1602 + 114 
bytes
gc_finalize_phase(JSContext * 0x03406b08, unsigned int 1024) line 946 + 11 bytes
js_GC(JSContext * 0x03406b08, unsigned int 0) line 1194 + 13 bytes
...
PL_ProcessPendingEvents(PLEventQueue * 0x00b36028) line 509 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00080236, unsigned int 49395, unsigned int 0, 
long 11755560) line 1054 + 9 bytes
...
nsAppShellService::Run(nsAppShellService * const 0x00b323e0) line 408
...

and this

(crash)
js_AllocGCThing(JSContext * 0x00ce9d50, unsigned int 0) line 420 + 41 bytes
js_NewObject(JSContext * 0x00ce9d50, JSClass * 0x0117ae58 struct JSClass  
XULElementClass, JSObject * 0x028c88f8, JSObject * 0x02a168b0) line 1442 + 11 
bytes
JS_NewObject(JSContext * 0x00ce9d50, JSClass * 0x0117ae58 struct JSClass  
XULElementClass, JSObject * 0x028c88f8, JSObject * 0x02a168b0) line 1892 + 21 
bytes
NS_NewScriptXULElement(nsIScriptContext * 0x00ce9cd8, nsISupports * 0x029966dc, 
nsISupports * 0x00cd3f68, void * * 0x02996710) line 730 + 23 bytes
...
XULPopupListenerImpl::LaunchPopup(int 408, int 92) line 673
XULPopupListenerImpl::sTooltipCallback(nsITimer * 0x03083c68, void * 0x0311c000) 
line 717
nsTimer::Fire() line 194 + 17 bytes
nsTimerManager::FireNextReadyTimer(nsTimerManager * const 0x00cd3e60, unsigned 
int 0) line 117
FireTimeout(HWND__ * 0x00000000, unsigned int 275, unsigned int 10132, unsigned 
long 31316718) line 89
...
nsDebug::Assertion(const char * 0x013066c4, const char * 0x013066b0, const char * 
0x01306668, int 776) line 215 + 22 bytes
WrappedNative_Finalize(JSContext * 0x03217aa8, JSObject * 0x0325cd90) line 776 + 
58 bytes
js_FinalizeObject(JSContext * 0x03217aa8, JSObject * 0x0325cd90) line 1602 + 114 
bytes
gc_finalize_phase(JSContext * 0x03217aa8, unsigned int 1024) line 946 + 11 bytes
js_GC(JSContext * 0x03217aa8, unsigned int 0) line 1194 + 13 bytes
...
PL_ProcessPendingEvents(PLEventQueue * 0x00b65f98) line 509 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00200146, unsigned int 49395, unsigned int 0, 
long 11952024) line 1054 + 9 bytes

meaning that, as we already knew, the event loop in the system modal alert is a 
wide open door for things to happen which can cause, among other things, JS to be 
executed. I was thinking we could borrow a page from our own modal windows which 
were more careful about freezing execution (by preventing NSPR event loop 
reentrancy) but I see that wouldn't help here, either. And clearly no MessageBox 
flag will make any difference.
  /me withdraws his offer of help and runs, looking for a cardboard box to hide 
under. Seems to me there are places in our core code where you just can't be 
tossing up windows, is all. Or do you guys have some clever bulletproofing 
scheme?

The top of the stack traces look similar to bug 52859 and bug 67937. Could they
all be related somehow?
Maybe we should fix this f'in bug. I wonder how much developer and QA effort is
wasted by tripping over it. Doug, is there really any possibility that the Win32
event loop system will be modified to allow the messages for the modal debug
dialog to get through without *any* other events getting through to the app? I
didn't think so. 

It seems like the source of the problem is the *old* mozilla problem of coders
on different platforms having differenet expectations of assertions. We've
battled this through over and over and never resolved it. The 'nix people are
happy to see those assertions go by as they contine to use the app. The 'dows
people really seem to want the choice of {abort,debug,ignore} and would revolt
if they weren't given the option to debug at an assert point. IIRC, warren was
especially unhappy at the prospect of waiting while the app *automatically*
launched the debugger each time an assert was hit.

Maybe choice is good, but showing a modal dialog from the app is bad. What are
the other options? 

- Maybe an environment setting to allow the user to 'pre-state' what they want
to have happen when an assert happens. This would be easy, but inflexible.

- Or maybe we write a trivial little single dialog application to replace the
functionality of that stupid modal dialog (that doesn't even have the correct
button labels!) and launch it using CreateProcess and wait for the user to
choose before continuing. This would be fairly easy to do and would give us a
dialog that actually showed the assert info. I could imagine writing this one
afternoon.

Thoughts?

Mack: bug 52859 is something else. But, bug 67937 and bug 67354 are crashing
because of this. And who knows how many others!
This bug really belongs to Danm.  I am reassigning it.
Assignee: dougt → danm
OK, worse is better. Rather than blow an afternoon, I blew an hour. This 
solution doesn't bother with a fancier dialog ('retry' is just destined to mean 
'debug' - we all know that!) .I tested to make sure it would work even if the 
current working directory had changed. If for any reason the dialog app does not 
get launched then we just try to launch the debugger. It works for me on NT4. 
Comments? r= ? sr= ?
Assignee: danm → jband
jband: you can use cvs diff -uN to include new files, IIRC.

Should we have an xpcom/windbgdlg subdir, or would it be better to put that
stuff under xpcom/debug and maybe let other platforms play?

/be
brendan: I didn't know about cvs diff -uN. Thanks.

AFAIK our windows make system is not happy with making a static lib and an exe 
out of the same source directory.
Let's get this in, it just bit bryner in a confusing way.  danm, can you r=? 
Cc'ing other r/sr= candidates.

/be
  Heh heh heh. I admire this patch for its use of the whammo hammer. I tried it 
and seemed to have some trouble getting a debug alert to happen, so I didn't get 
my personal demo, but I trust John. Sign me up. r=me.

Dan, what problem did you have? This is working for me.
Anyone else want to give it a try?
Status: NEW → ASSIGNED
The problem I was having was simply that I seemed to be having trouble getting a 
legitimate error dialog at all. I tried it again today and got an assertion to 
fail. I got the happy little dialog. r=me for real.

I'll rs=/sr= so this can go in and get rid of spurious crashes.

/be
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Component: XP Utilities → XPCOM
Keywords: verifyme
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: