Closed
Bug 54792
Opened 24 years ago
Closed 24 years ago
nsDebug::Assertion does not prevent re-entry into the main window
Categories
(Core :: XPCOM, defect, P3)
Tracking
()
RESOLVED
FIXED
People
(Reporter: jrgmorrison, Assigned: jband_mozilla)
References
()
Details
Attachments
(3 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
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()
Reporter | ||
Comment 1•24 years ago
|
||
Er, sorry. Meant to include the bug number where this condition was originally
noted -- bug 53953.
Comment 6•24 years ago
|
||
Lotta dups, which means wasted time (yes, mine too, which makes me grumpy). Is
there an easy fix to the MessageBox call?
/be
Assignee | ||
Comment 7•24 years ago
|
||
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.
Comment 8•24 years ago
|
||
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.
Comment 10•24 years ago
|
||
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
Assignee | ||
Comment 11•24 years ago
|
||
Assignee | ||
Comment 12•24 years ago
|
||
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!
Comment 13•24 years ago
|
||
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?
Comment 14•24 years ago
|
||
Assignee | ||
Comment 15•24 years ago
|
||
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?
Assignee | ||
Comment 16•24 years ago
|
||
Comment 17•24 years ago
|
||
This bug really belongs to Danm. I am reassigning it.
Assignee: dougt → danm
Assignee | ||
Comment 18•24 years ago
|
||
Assignee | ||
Comment 19•24 years ago
|
||
Assignee | ||
Comment 20•24 years ago
|
||
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
Comment 21•24 years ago
|
||
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
Assignee | ||
Comment 22•24 years ago
|
||
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.
Comment 23•24 years ago
|
||
Let's get this in, it just bit bryner in a confusing way. danm, can you r=?
Cc'ing other r/sr= candidates.
/be
Comment 24•24 years ago
|
||
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.
Assignee | ||
Comment 25•24 years ago
|
||
Dan, what problem did you have? This is working for me.
Anyone else want to give it a try?
Status: NEW → ASSIGNED
Comment 26•24 years ago
|
||
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.
Comment 27•24 years ago
|
||
I'll rs=/sr= so this can go in and get rid of spurious crashes.
/be
Assignee | ||
Comment 28•24 years ago
|
||
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•