Last Comment Bug 780511 - Pipe additional output to the Windows debugger console
: Pipe additional output to the Windows debugger console
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: General (show other bugs)
: Trunk
: x86_64 Windows 7
: -- normal (vote)
: mozilla17
Assigned To: Jim Mathies [:jimm]
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-05 14:41 PDT by Jim Mathies [:jimm]
Modified: 2013-04-30 10:19 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (3.50 KB, patch)
2012-08-05 14:41 PDT, Jim Mathies [:jimm]
neil: review+
Details | Diff | Review
updated patch (3.91 KB, patch)
2012-08-06 12:09 PDT, Jim Mathies [:jimm]
no flags Details | Diff | Review

Description Jim Mathies [:jimm] 2012-08-05 14:41:58 PDT
Created attachment 649136 [details] [diff] [review]
patch

console output, component load, and Dump in frame manager.
Comment 1 neil@parkwaycc.co.uk 2012-08-06 11:54:52 PDT
Comment on attachment 649136 [details] [diff] [review]
patch

>+    OutputDebugStringW(aStr.BeginReading());
BeginReading doesn't guarantee null-termination, so use PromiseFlatString(aStr).get() instead. r=me with that fixed. It's a shame that nsGlobalWindow::Dump uses OutputDebugStringA though :-(

>+            nsXPIDLString msg;
I have a slight preference for nsString here because nsXPIDLString::get can return nullptr.

>+            message->GetMessageMoz(getter_Copies(msg));
>+            OutputDebugStringW(msg.get());
>+            OutputDebugStringW(L"\n");
I'd prefer if you appended the newline to the string before outputting it, this makes the debugger output pane update more smoothly (it tries to keep the last character on screen which is hard when the line of text exceeds the window width).
Comment 2 Jim Mathies [:jimm] 2012-08-06 12:04:08 PDT
(In reply to neil@parkwaycc.co.uk from comment #1)
> Comment on attachment 649136 [details] [diff] [review]
> patch
> 
> >+    OutputDebugStringW(aStr.BeginReading());
> BeginReading doesn't guarantee null-termination, so use
> PromiseFlatString(aStr).get() instead. r=me with that fixed. It's a shame
> that nsGlobalWindow::Dump uses OutputDebugStringA though :-(

Has that caused problems for non-ascii output? I could probably update it if the wide char data is available there.
Comment 3 Jim Mathies [:jimm] 2012-08-06 12:09:48 PDT
Created attachment 649340 [details] [diff] [review]
updated patch
Comment 5 Ed Morley [:emorley] 2012-08-07 07:37:55 PDT
https://hg.mozilla.org/mozilla-central/rev/ac4ee04df5e2
Comment 6 neil@parkwaycc.co.uk 2012-08-15 09:10:25 PDT
(In reply to Jim Mathies from comment #2)
> (In reply to neil@parkwaycc.co.uk from comment #1)
> > >+    OutputDebugStringW(aStr.BeginReading());
> > BeginReading doesn't guarantee null-termination, so use
> > PromiseFlatString(aStr).get() instead. r=me with that fixed. It's a shame
> > that nsGlobalWindow::Dump uses OutputDebugStringA though :-(
> Has that caused problems for non-ascii output? I could probably update it if
> the wide char data is available there.
I don't know, I don't get to dump much non-ASCII output, but the wide char data is certainly available via PromiseFlatString(aStr).get() again ;-)
Comment 7 Ted Mielczarek [:ted.mielczarek] 2013-04-30 08:32:01 PDT
This makes running Firefox in a debugger super-slow. I'm using a Nightly with WinDBG attached to try to catch an intermittent OOM, and every time I load a page the whole browser is unresponsive because it's feeding tons of error console output to the debugger.
Comment 8 Jim Mathies [:jimm] 2013-04-30 09:25:05 PDT
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #7)
> This makes running Firefox in a debugger super-slow. I'm using a Nightly
> with WinDBG attached to try to catch an intermittent OOM, and every time I
> load a page the whole browser is unresponsive because it's feeding tons of
> error console output to the debugger.

We could add a build config flag that disables calls to OutputDebugString.
Comment 9 Ted Mielczarek [:ted.mielczarek] 2013-04-30 09:42:25 PDT
I think I'd be happy if we could just revert the bit that feeds the error console to the debugger. That seems to be what's causing me the most grief.
Comment 10 Jim Mathies [:jimm] 2013-04-30 10:19:35 PDT
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #9)
> I think I'd be happy if we could just revert the bit that feeds the error
> console to the debugger. That seems to be what's causing me the most grief.

Hmm, that output is really useful when you're remote debugging metrofx on a Win8 tablet.

Note You need to log in before you can comment on or make changes to this bug.