559454 - Debug mochitest 1/5 and 3/5 fail on Rev3 Fedora slaves with "XOpenDisplay() failed" "firefox-bin: Fatal IO error 104 (Connection reset by peer) on X server :0.0."

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(Need the full logs to see the error)

http://tinderbox.mozilla.org/showlog.cgi?tree=Firefox&errorparser=unittest&logfile=1271280140.1271281337.31539.gz&buildtime=1271280140&buildname=Rev3%20Fedora%2012%20mozilla-central%20debug%20test%20mochitests-1%2f5&fulltext=1
Rev3 Fedora 12 mozilla-central debug test mochitests-1/5 on 2010/04/14 14:22:20  
s: talos-r3-fed-027
5442 INFO Running /tests/content/base/test/test_bug364413.xhtml...
XOpenDisplay() failed
firefox-bin: Fatal IO error 104 (Connection reset by peer) on X server :0.0.
Leaked URLs:

http://tinderbox.mozilla.org/showlog.cgi?tree=Firefox&errorparser=unittest&logfile=1271280141.1271281262.31338.gz&buildtime=1271280141&buildname=Rev3%20Fedora%2012%20mozilla-central%20debug%20test%20mochitests-3%2f5&fulltext=1#err0
Rev3 Fedora 12 mozilla-central debug test mochitests-3/5 on 2010/04/14 14:22:21  
s: talos-r3-fed-030
pldhash: for the table at address 0xa846500, the given entrySize of 52 probably favors chaining over double hashing.
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520012: file /builds/slave/mozilla-central-linux-debug/build/chrome/src/nsChromeRegistry.cpp, line 1363
++DOMWINDOW == 11 (0xa89e390) [serial = 11] [outer = 0xa664678]
firefox-bin: Fatal IO error 104 (Connection reset by peer) on X server :0.0.
Leaked URLs:

This is the same error described in bug 476554.  Might it possibly be related to bug 558521 in that a Gtk upgrade would fix?  (Seems unlikely.)

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to comment #0)
> This is the same error described in bug 476554.

The same X error, that is.  Shaver suggests it might be the X server getting OOM killed.

Comment 2

[Karl Tomlinson (:karlt)]

What starts the X server?
Is its output logged somewhere?

Comment 3

[Armen [:armenzg]]

This hasn't happened for a while and I can't go that far in time on buildbot to get more information.

I will have to jump on as soon as you post a new log.

It is weird for me to see that DISPLAY=:0.0 when in our configs we only have it set to DISPLAY=:0

I will check again in a week but this bug sounds like WORKSFORME. Let me know what your thoughts are.

Comment 4

[Ed Morley [:emorley]]

Mass marking whiteboard:[orange] bugs WFM (to clean up TBPL bug suggestions) that:
* Haven't changed in > 6months
* Whose whiteboard contains none of the strings: {disabled,marked,random,fuzzy,todo,fails,failing,annotated,leave open,time-bomb}
* Passed a (quick) manual inspection of bug summary/whiteboard to ensure they weren't a false positive.

I've also gone through and searched for cases where the whiteboard wasn't labelled correctly after test disabling, by using attachment description & basic comment searches. However if the test for which this bug was about has in fact been disabled/annotated/..., please accept my apologies & reopen/mark the whiteboard appropriately so this doesn't get re-closed in the future (and please ping me via IRC or email so I can try to tweak the saved searches to avoid more edge cases).

Sorry for the spam! Filter on: #FFA500