Improve ipc debug output for unhandled nonqueued Windows messages

RESOLVED FIXED in mozilla34

Status

()

Core
DOM: Content Processes
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: jimm, Assigned: jimm)

Tracking

(Blocks: 1 bug)

Trunk
mozilla34
x86_64
Windows 7
Points:
---
Bug Flags:
qe-verify -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

30.50 KB, patch
jimm
: review+
Details | Diff | Splinter Review
(Assignee)

Description

4 years ago
I'm working on a patch that improves this output for better debugging.
(Assignee)

Updated

4 years ago
Summary: Improve debug output for unhandled ipc nonqueued Windows messages → Improve ipc debug output for unhandled nonqueued Windows messages
(Assignee)

Comment 1

4 years ago
[14384] ###!!! ASSERTION: Received "nonqueued" ui message "WM_PAINT" during a synchronous IPC message for window 0x2C0538 ("MozillaTaskbarPreviewClass"), sending it to DefWindowProc instead of the normal window procedure.
[14384] ###!!! ASSERTION: Received "nonqueued" ui message (0x11B) during a synchronous IPC message for window 0x2C0538 ("MozillaTaskbarPreviewClass"), sending it to DefWindowProc instead of the normal window procedure.
[14384] ###!!! ASSERTION: Received "nonqueued" WM_USER message (0x400) during a synchronous IPC message for window 0x2C0538 ("MozillaTaskbarPreviewClass"), sending it to DefWindowProc instead of the normal window procedure.
[14384] ###!!! ASSERTION: Received "nonqueued" WM_APP message (0x8000) during a synchronous IPC message for window 0x2C0538 ("MozillaTaskbarPreviewClass"), sending it to DefWindowProc instead of the normal window procedure.
[14384] ###!!! ASSERTION: Received "nonqueued" registered windows message (0xC2F6) during a synchronous IPC message for window 0x2C0538 ("MozillaTaskbarPreviewClass"), sending it to DefWindowProc instead of the normal window procedure.
[14384] ###!!! ASSERTION: Received "nonqueued" system message (0x10000) during a synchronous IPC message for window 0x2C0538 ("MozillaTaskbarPreviewClass"), sending it to DefWindowProc instead of the normal window procedure.
(Assignee)

Comment 2

4 years ago
Created attachment 8471560 [details] [diff] [review]
patch v.1
Attachment #8471560 - Flags: review?(bent.mozilla)
(Assignee)

Comment 3

4 years ago
Created attachment 8471562 [details] [diff] [review]
patch v.1

- without my test output calls DumpNeuteredMessage
Attachment #8471560 - Attachment is obsolete: true
Attachment #8471560 - Flags: review?(bent.mozilla)
Attachment #8471562 - Flags: review?(bent.mozilla)
Comment on attachment 8471562 [details] [diff] [review]
patch v.1

Review of attachment 8471562 [details] [diff] [review]:
-----------------------------------------------------------------

This looks pretty good to me!

::: widget/windows/WinUtils.cpp
@@ +60,5 @@
>  namespace mozilla {
>  namespace widget {
>  
> +EventMsgInfo gAllEvents[] = {
> +  {"WM_NULL",                             0x0000},

I think these would be better with a macro, something like:

  EventMsgInfo gAllEvents[] = {
    #define ENTRY(_msg) { #_msg, _msg }

    ENTRY(WM_NULL),
    ENTRY(WM_CREATE),
    // ...

    #undef ENTRY
  }

That way you don't have to worry about typos in the name or value.

::: widget/windows/WinUtils.h
@@ +76,5 @@
> +typedef struct {
> +  const char * mStr;
> +  UINT         mId;
> +} EventMsgInfo;
> +extern EventMsgInfo gAllEvents[];

Seems like this should be DEBUG-only right?
Attachment #8471562 - Flags: review?(bent.mozilla) → review+
(Assignee)

Comment 5

4 years ago
> I think these would be better with a macro, something like:
> 
>   EventMsgInfo gAllEvents[] = {
>     #define ENTRY(_msg) { #_msg, _msg }
> 
>     ENTRY(WM_NULL),
>     ENTRY(WM_CREATE),
>     // ...
> 
>     #undef ENTRY
>   }
> 
> That way you don't have to worry about typos in the name or value.

great idea, updated.

> ::: widget/windows/WinUtils.h
> @@ +76,5 @@
> > +typedef struct {
> > +  const char * mStr;
> > +  UINT         mId;
> > +} EventMsgInfo;
> > +extern EventMsgInfo gAllEvents[];
> 
> Seems like this should be DEBUG-only right?

Hmm, not really, but it could be. The code in nsWindowDbg that references this works in both debug and release. Not sure if we need to clean that up, the linker should get rid of this table if its not in use.
(Assignee)

Comment 6

4 years ago
Created attachment 8471771 [details] [diff] [review]
patch v.2

v1 try push - https://tbpl.mozilla.org/?tree=Try&showall=0&rev=0e5318389b69

debug mochitest-3 has some of these new warnings in it.

v2 try push - https://tbpl.mozilla.org/?tree=Try&showall=0&rev=d7dbb7912c60
Attachment #8471562 - Attachment is obsolete: true
Attachment #8471771 - Flags: review+

Comment 8

4 years ago
https://hg.mozilla.org/mozilla-central/rev/b3c4148afdd4
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Flags: qe-verify-
You need to log in before you can comment on or make changes to this bug.