Server panicked about midnight PST.. Really not much more to say..
|-||Supermarket||4m||Sleep is a sexy lover.|
|-||Scarlyt||23m||<3 <3 <3 The admins are the bestest! <3 <3 <3|
|-||Grizzly666||1m||Oh no! I lost my knife in a hookers belly!|
|-||White||16m||I am just a boy.|
|-||Jameson||45m||making the eternal black firmament my side bitch|
|c||Mephisto||4s||Malt doch nicht immer den Teufel an die Wand.|
|j||Johnny||22h||New Code Written Nightly. Not a GM.|
|a||Cerberus||25s||Head Builder & GM when I need to|
|And 30 more hiding and/or disguised|
In our case, a sig 11.
Signal 11, or officially know as "segmentation fault", means that the program accessed a memory location that was not assigned.
Mainly this happens (in stable production systems like ours) due to timing problems in the CPU <-> cache <-> memory path, but other explinations include stray alpha particles randomly flipping a bit, and of course, software bugs.
I'm pretty convinced it's not a LambdaMOO issue (if it were we should be able to reproduce it with the same hour old database before the panic), which leaves my custom compiled kernel, and the hardware as the possible culprits.
Take your pick.
One day I may upgrade the kernel to a newer version, but as this one has been solid save a few panics after 2+ months straight of uptime, It's not a priority. Why fix what's (mostly) not broken?