http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1271791419.1271796208.27060.gz Linux x86-64 mozilla-central build on 2010/04/20 12:23:39 s: moz2-linux64-slave05 { make[2]: Entering directory `/builds/slave/mozilla-central-linux64/build/obj-firefox/js/src/jsapi-tests' ../../../dist/bin/run-mozilla.sh ../../../dist/bin/jsapi-tests ../../../dist/bin/jsapi-tests: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ../../../dist/bin/jsapi-tests) make[2]: *** [check] Error 1 make[2]: Leaving directory `/builds/slave/mozilla-central-linux64/build/obj-firefox/js/src/jsapi-tests' make[1]: *** [check] Error 2 /tools/python/bin/python2.5 /builds/slave/mozilla-central-linux64/build/js/src/config/check-sync-dirs.py /builds/slave/mozilla-central-linux64/build/js/src/config /builds/slave/mozilla-central-linux64/build/config TEST-PASS | check-sync-dirs.py | /builds/slave/mozilla-central-linux64/build/js/src/config <= /builds/slave/mozilla-central-linux64/build/config /tools/python/bin/python2.5 /builds/slave/mozilla-central-linux64/build/js/src/config/check-sync-dirs.py /builds/slave/mozilla-central-linux64/build/js/src/build /builds/slave/mozilla-central-linux64/build/build } Seamonkey apparently hits this (frequently?) too, and they haven't turned on |make check| as a result -- see bug 556668 comment 0 through 3.

Filing under RelEng since bug 556668 comment 4 indicate that this could be a library issue on the Linux x64 boxes. (or something else broken that makes it look like that)

Perhaps bug 554854 will fix this? (It's about updating glibc on linux slaves, and it's marked as blocking bug 556668)

We just hit this again: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1271861881.1271866548.9848.gz Linux x86-64 mozilla-central build on 2010/04/21 07:58:01 s: moz2-linux64-slave05

So, my first suspicion is that we need to be running with LD_LIBRARY_PATH set to pick up the libraries in /tools/gcc-4.2.3. I'd expect this to be a consistent failure if that were the case though. The system has gcc 4.1.1 installed. The gcc-4.2.3 binaries and libraries aren't in the system search paths.

moz2-linux64-slave05 didn't have puppet running, I've taken it out of the pool for now.

When we determine how to fix this on moz2-linux64-slave05, we'll probably want a similar fix at a more general level (or in the pre-made reference platform), to fix whatever's going wrong breaking in bug 556668.

So, let's see if fixing bug 560908 fixes this issue. There are compiler differences between slave05 and other slaves because the configuration management software isn't running on slave05. I'm not sure how this would result in sporadic problems on this slave how.

I don't understand how this could be an intermittent failure unless there are differences between our buildslaves (which would be really bad).

(In reply to comment #8) > I don't understand how this could be an intermittent failure To clarify: it's only intermittent in the sense that it was only happening on one build machine (and hence only showing up on tinderbox intermittently) -- moz2-linux64-slave05 -- per comment 5 and 6. (I'm not sure whether it was perma-fail vs. intermittent *on that build slave*, though. In any case, I don't think the broken slave is still doing builds, per comment 5.) > unless there are > differences between our buildslaves (which would be really bad). It looks like there are (though I think they were unintentional and might now be addressed?) -- see comment 7.

This hasn't happened since taking that bad slave out of the pool. Re-open if it happens again.

Not sure if I should be reopening this or not -- on try server, I see this failure with a particular patch that introduces a dependency in libxul on a particular versioned symbol: 0000000000000000 DF *UND* 00000000000002b2 GLIBCXX_3.4.9 _ZNSo9_M_insertIdEERSoT_ From the log, no LD_LIBRARY_PATH or anything is being set anywhere in the environment. jsapi-tests (the original problem here) are running fine, I'm hitting this on the xpcom tests; but I don't see any GLIBCXX_3.4.9 deps in libmozjs.so so it must have been taken out since then. Log file: http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1279142586.1279148302.28883.gz

Comment #11 to be addressed in bug 578880.

I saw this on two different slaves today on try: http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1288038838.1288040193.21559.gz&fulltext=1 http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1288038838.1288044939.11372.gz&fulltext=1 Might be because I'm using string streams in my test now, but other tests that use it are running just fine just before it, so I don't think that's it.