683792 - Possible bad RAM on moz2-darwin10-slave52

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Phil Ringnalda (:philor)]

jseward left you a message, by way of an internal bzip error, saying that he thinks the memory on moz2-darwin10-slave52 is going bad. https://tbpl.mozilla.org/php/getParsedLog.php?id=6219849 says

bzip2/libbzip2: internal error number 1007.
This is a bug in bzip2/libbzip2, 1.0.5, 10-Dec-2007.
Please report it to me at: [e-mail].  If this happened
when you were using some program which uses libbzip2 as a
component, you should also report this bug to the author(s)
of that program.  Please make an effort to report this bug;
timely and accurate bug reports eventually lead to higher
quality software.  Thanks.  Julian Seward, 10 December 2007.


*** A special note about internal error number 1007 ***

Experience suggests that a common cause of i.e. 1007
is unreliable memory or other hardware.  The 1007 assertion
just happens to cross-check the results of huge numbers of
memory reads/writes, and so acts (unintendedly) as a stress
test of your memory system.

I suggest the following: try compressing the file again,
possibly monitoring progress in detail with the -vv flag.

* If the error cannot be reproduced, and/or happens at different
  points in compression, you may have a flaky memory system.
  Try a memory-test program.  I have used Memtest86
  (www.memtest86.com).  At the time of writing it is free (GPLd).
  Memtest86 tests memory much more thorougly than your BIOSs
  power-on test, and may find failures that the BIOS doesn't.

* If the error can be repeatably reproduced, this is a bug in
  bzip2, and I would very much like to hear about it.  Please
  let me know, and, ideally, save a copy of the file causing the
  problem -- without which I will be unable to investigate it.

/builds/slave/m-in-osx64-dbg/build/build/package/mac_osx/pkg-dmg: hdiutil convert failed (cleaning up)

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

Disabled in slavealloc and buildslave stopped

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

This box had three failures in a row. The packaging error in comment #1, then a compiler crash:

/builds/slave/m-aurora-osx64/build/js/src/jsiter.cpp: In function 'bool js_SuppressDeletedProperty(JSContext*, JSObject*, jsid)':
/builds/slave/m-aurora-osx64/build/js/src/jsiter.cpp:903: internal compiler error: Segmentation fault

then another compiler crash/:
/builds/slave/m-in-osx64-dbg/build/netwerk/protocol/http/nsHttpChannel.cpp: In constructor 'nsHttpChannel::nsHttpChannel()':
/builds/slave/m-in-osx64-dbg/build/netwerk/protocol/http/nsHttpChannel.cpp:135: internal compiler error: Segmentation fault
Please submit a full bug report,

It rebooted each time according to 'last'.

Over to RelOps for investigation. Maybe Apple diagnostics and memtest86 ?

Comment 3

[Amy Rich [:arr] [:arich]]

It showed all of it's ram and didn't appear to have any issues apparent on the console.  It's been reimaged to see if that helps.  Back to you releng for puppetization and configuration.

Comment 4

[Amy Rich [:arr] [:arich]]

Actually, I had the monitor plugged in when this machine had a CPU panic.  We'll pull it for decommissioning.

Comment 5

[Amy Rich [:arr] [:arich]]

added to the spreadsheet.

Comment 6

[Armen [:armenzg]]

Moving to releng to fully decommission it.

Comment 7

[Armen [:armenzg]]

I am removing the slave in bug 700705 with a bunch of slaves.
Going back to previous summary.