If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Dehydra error in nsPresShell.cpp

RESOLVED FIXED

Status

()

Core
Rewriting and Analysis
RESOLVED FIXED
9 years ago
6 years ago

People

(Reporter: Benjamin Smedberg, Assigned: (dormant account))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

9 years ago
Created attachment 365468 [details] [diff] [review]
Debugging patch, rev. 1

The static analysis tinderbox is red compiling nsPresShell.cpp. It seems that one of the analyses is getting an unexpected (buggy) dehydra object.

The script is frame-verify.js: it's checking for and collecting instantiations of do_QueryFrame::operator (cast). decl.type.type is usually a pointer to the class being returned. But in this case, it's a nscoord type, which makes no sense.

Patch for debugging will be attached, as well as a beautified log.

This probably started with http://hg.mozilla.org/mozilla-central/rev/b095eaf3e8b4 which touched nsPresShell.cpp, but I don't see any particularly unusual or suspicious code in that checkin.
(Reporter)

Comment 1

9 years ago
Created attachment 365470 [details]
beautified log
(Assignee)

Comment 2

9 years ago
Can't reproduce this. I did hg up -r b095eaf3e8b4 and made sure than nsPresShell.o builds fine.

I did notice that spidermonkey is causing weird dehydra crashes all over the place, so perhaps you need to try a diff version?

I built mine from the trunk today.
(Reporter)

Comment 3

9 years ago
This happens to fix it locally:
diff --git a/layout/generic/nsFrame.h b/layout/generic/nsFrame.h
--- a/layout/generic/nsFrame.h
+++ b/layout/generic/nsFrame.h
@@ -440,6 +440,10 @@ public:
     ListTag(out, (nsIFrame*)this);
   }
 
+  static void IndentBy(FILE* out, PRInt32 aIndent) {
+    while (--aIndent >= 0) fputs("  ", out);
+  }
+  
   static void ListTag(FILE* out, nsIFrame* aFrame) {
     nsAutoString tmp;
     nsIFrameDebug*  frameDebug = do_QueryFrame(aFrame);
@@ -450,10 +454,6 @@ public:
     fprintf(out, "@%p", static_cast<void*>(aFrame));
   }
 
-  static void IndentBy(FILE* out, PRInt32 aIndent) {
-    while (--aIndent >= 0) fputs("  ", out);
-  }
-  
   static void XMLQuote(nsString& aString);
 
   /**

This makes me suspect timing issues, perhaps GC? (Either GCC frame GC, or JSGC).
(Reporter)

Comment 4

8 years ago
This popped again (in nsFrameManager.cpp, but with nscoord again). I really think this is related to GCC tree GC: What happens if GCC collects trees but dehydra doesn't know about it and the dehydra type map has pointers to trees which have been collected? If a new tree has the same address as an old tree, dehydra won't know about it.

I switch to treehydra to work around the problem: http://hg.mozilla.org/mozilla-central/rev/cc49a7b96493 but I think that GCC tree collection should be looked-into.
(Assignee)

Comment 5

8 years ago
Created attachment 393513 [details] [diff] [review]
possible fix
(Assignee)

Comment 6

8 years ago
http://hg.mozilla.org/rewriting-and-analysis/dehydra/rev/7cdeb7be1671
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Updated

6 years ago
Assignee: nobody → tglek
You need to log in before you can comment on or make changes to this bug.