481454 - Dehydra error in nsPresShell.cpp

Status: RESOLVED FIXED

(Developer Infrastructure :: Source Code Analysis, defect)

Description

[Benjamin Smedberg]

Attachment: 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.

Comment 1

[Benjamin Smedberg]

Attachment: beautified log

Comment 2

[(dormant account)]

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.

Comment 3

[Benjamin Smedberg]

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).

Comment 4

[Benjamin Smedberg]

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.

Comment 5

[(dormant account)]

Attachment: possible fix

Comment 6

[(dormant account)]

http://hg.mozilla.org/rewriting-and-analysis/dehydra/rev/7cdeb7be1671