#67 hashlife segfaulted
Hi! Thanks for the awesome simulator, it's very enjoyable and useful for explorations! Started using it a few days ago, I've had success with a few patterns, but today I encountered the following bug:
I'm trying to execute the following command:
⟫ bgolly -h -M 70000 -m 999999999990 -o 2tsim.mc 2tinit.mc
This is bgolly 5.0 Copyright 2005-2025 The Golly Gang.
bgolly -h -M 70000 -m 999999999990 -o 2tsim.mc 2tinit.mc
0: 2,000,000,000,001
2: 3,999,999,999,997
6: 7,999,999,999,989
22: 15,999,999,999,764
54: 31,999,999,998,925
118: 63,999,999,994,999
246: 127,999,999,976,550
502: 255,999,999,894,802
1,014: 511,999,999,548,075
2,038: 1,023,999,998,108,863
4,086: 2,047,999,992,180,362
69,622: 4,095,999,752,898,000
331,766: 8,191,997,690,223,654
2,428,918: 16,383,969,991,047,631
10,817,526: 32,767,745,865,066,689
77,926,390: 65,533,274,434,454,259
346,361,846: 131,050,991,740,933,702
1,420,103,670: 261,997,154,730,914,933
3,567,587,318: 523,398,349,251,551,804
Segmentation fault (core dumped) <-- about 1h into the simulation, with the previous milestones timing showing simulation complexity which is sublinear but probably ω(log T)
I got the same result with 110GB of memory allocated to it, and with just 30. The machine had 128, 4 used.
For the 110GB run, the segfault occured when about 70GB of memory were used
Golly compiled from this repo today, Ubuntu.
The initial pattern file is of course attached, and it has a very simple mathematical description (standard Conway rule):
A0 := {0}×{1,2,..,n} ∪ {(1,1)} (up to a global shift), n=2e12, so just a segment and one cell atop of its left end. (Without the extra cell it settles down to a very clean Sierpinski triangle-like repeating pattern, this single cell adds quite a noticeable amount of chaos to it, but nevertheless with sufficient structure for HashLife to be vastly more efficient than brute force simulation)
I also attach a Golly script that generates this for any n. This mc file was generated on a different machine, with a slightly different Golly installation (but also very recent, from source, Ubuntu) via GUI (since bgolly doesn't support scripts afaik?)
The simulation succeeded when the segment ray was 10B, and time was 5B steps. The segfault place differs from time to time
I compiled with -g -O0 and ran under gdb:
...
346,361,846: 131,050,991,740,933,702
1,420,103,670: 261,997,154,730,914,933
3,567,587,318: 523,398,349,251,551,804
Program received signal SIGSEGV, Segmentation fault.
0x000000000040f8ae in hlifealgo::findnode(setupt&) ()
(gdb) bt
0 0x000000000040f8ae in hlifealgo::findnode(setupt&) ()
1 0x0000000000413a30 in hlifealgo::dorecurs(node, node, node, node, int) ()
2 0x00000000004131f7 in hlifealgo::getres(node, int) ()
3 0x0000000000413c5c in hlifealgo::dorecurs(node, node, node, node, int) ()
4 0x00000000004131f7 in hlifealgo::getres(node, int) ()
5 0x0000000000413c5c in hlifealgo::dorecurs(node, node, node, node, int) ()
6 0x00000000004131f7 in hlifealgo::getres(node, int) ()
7 0x0000000000413c5c in hlifealgo::dorecurs(node, node, node, node, int) ()
8 0x00000000004131f7 in hlifealgo::getres(node, int) ()
9 0x0000000000413c79 in hlifealgo::dorecurs(node, node, node, node, int) ()
10 0x00000000004131f7 in hlifealgo::getres(node, int) ()
11 0x0000000000413a91 in hlifealgo::dorecurs(node, node, node, node, int) ()
12 0x00000000004131f7 in hlifealgo::getres(node, int) ()
13 0x0000000000413c5c in hlifealgo::dorecurs(node, node, node, node, int) ()
14 0x00000000004131f7 in hlifealgo::getres(node, int) ()
15 0x0000000000413a5d in hlifealgo::dorecurs(node, node, node, node, int) ()
16 0x00000000004131f7 in hlifealgo::getres(node, int) ()
17 0x0000000000413a3d in hlifealgo::dorecurs(node, node, node, node, int) ()
18 0x00000000004131f7 in hlifealgo::getres(node, int) ()
19 0x0000000000413a6f in hlifealgo::dorecurs(node, node, node, node, int) ()
20 0x00000000004131f7 in hlifealgo::getres(node, int) ()
21 0x00000000004139cf in hlifealgo::dorecurs(node, node, node, node, int) ()
22 0x00000000004131f7 in hlifealgo::getres(node, int) ()
23 0x0000000000413c5c in hlifealgo::dorecurs(node, node, node, node, int) ()
24 0x00000000004131f7 in hlifealgo::getres(node, int) ()
25 0x0000000000413aa5 in hlifealgo::dorecurs(node, node, node, node, int) ()
26 0x00000000004131f7 in hlifealgo::getres(node, int) ()
27 0x00000000004139ee in hlifealgo::dorecurs(node, node, node, node, int) ()
28 0x00000000004131f7 in hlifealgo::getres(node, int) ()
29 0x0000000000413cb9 in hlifealgo::dorecurs(node, node, node, node, int) ()
30 0x00000000004131f7 in hlifealgo::getres(node, int) ()
31 0x0000000000413c5c in hlifealgo::dorecurs(node, node, node, node, int) ()
32 0x00000000004131f7 in hlifealgo::getres(node, int) ()
33 0x0000000000413a6f in hlifealgo::dorecurs(node, node, node, node, int) ()
34 0x00000000004131f7 in hlifealgo::getres(node, int) ()
35 0x0000000000413a5d in hlifealgo::dorecurs(node, node, node, node, int) ()
36 0x00000000004131f7 in hlifealgo::getres(node, int) ()
37 0x0000000000413a5d in hlifealgo::dorecurs(node, node, node, node, int) ()
--Type for more, q to quit, c to continue without paging--
38 0x00000000004131f7 in hlifealgo::getres(node, int) ()
39 0x0000000000413a5d in hlifealgo::dorecurs(node, node, node, node, int) ()
40 0x00000000004131f7 in hlifealgo::getres(node, int) ()
41 0x0000000000413a1d in hlifealgo::dorecurs(node, node, node, node, int) ()
42 0x00000000004131f7 in hlifealgo::getres(node, int) ()
43 0x00000000004134c5 in hlifealgo::dorecurshalf(node, node, node, node, int) ()
44 0x000000000041338a in hlifealgo::getres(node, int) ()
45 0x00000000004134c5 in hlifealgo::dorecurshalf(node, node, node, node, int) ()
46 0x000000000041338a in hlifealgo::getres(node, int) ()
47 0x00000000004134c5 in hlifealgo::dorecurshalf(node, node, node, node, int) ()
48 0x000000000041338a in hlifealgo::getres(node, int) ()
49 0x00000000004134c5 in hlifealgo::dorecurshalf(node, node, node, node, int) ()
50 0x000000000041338a in hlifealgo::getres(node, int) ()
51 0x00000000004134c5 in hlifealgo::dorecurshalf(node, node, node, node, int) ()
52 0x000000000041338a in hlifealgo::getres(node, int) ()
53 0x00000000004134c5 in hlifealgo::dorecurshalf(node, node, node, node, int) ()
54 0x000000000041338a in hlifealgo::getres(node, int) ()
55 0x00000000004134c5 in hlifealgo::dorecurshalf(node, node, node, node, int) ()
56 0x000000000041338a in hlifealgo::getres(node, int) ()
57 0x0000000000415cd1 in hlifealgo::runpattern() ()
58 0x0000000000416138 in hlifealgo::step() ()
59 0x00000000004076e0 in main ()
(gdb) r
Starting program: /home/elexunix/aprog/build/great-alexus/golly/bgolly -h -M 100000 -m 1000000000000 /home/elexunix/ap
rog/golly/Aelexunix/2tinit.mc
warning: File "/usr/local/lib64/libstdc++.so.6.0.34-gdb.py" auto-loading has been declined by your `auto-load safe-pat
h' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /usr/local/lib64/libstdc++.so.6.0.34-gdb.py
line to your configuration file "/home/elexunix/.config/gdb/gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/elexunix/.config/gdb/gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
[Thread debugging using libthreaddb enabled]
Using host libthreaddb library "/lib/x8664-linux-gnu/libthreaddb.so.1".
This is bgolly 5.0 Copyright 2005-2025 The Golly Gang.
/home/elexunix/aprog/build/great-alexus/golly/bgolly -h -M 100000 -m 1000000000000 /home/elexunix/aprog/golly/Aelex
unix/2tinit.mc
0: 2,000,000,000,001
4,096: 4,000,000,548,311
69,632: 8,000,037,521,849
331,776: 16,000,402,755,858
2,428,928: 32,009,708,743,352
10,817,536: 64,099,641,436,759
Program received signal SIGSEGV, Segmentation fault.
hlifealgo::findleaf (this=this@entry=0x7ffff7f9a010, nw=nw@entry=8499, ne=ne@entry=34952, sw=sw@entry=8460, se=se@ent
ry=34018) at ../gollybase/hlifealgo.cpp:235
235 if (nw == p->nw && ne == p->ne && sw == p->sw && se == p->se &&
(gdb) p nw
$1 = 8499
(gdb) p ne
$2 = 34952
(gdb) p sw
$3 = 8460
(gdb) p se
$4 = 34018
(gdb) p p
$5 = (leaf ) 0x4000000000
(gdb) p p
Cannot access memory at address 0x4000000000
(gdb)
(I pasted here from plain cat issue | xsel -ib, the website editor decided to use different fonts)
Discussion
I tried running for about 6 hours but I couldn't reproduce the failure.
Is it possible that the bug is caused by bad hardware? Can you try running a tool like memtest86+ for several hours, and see if it finds any errors?
I think there are two reasons to suspect this:
The invalid address 0x4000000000 happens to be a null pointer with a single bit flipped. This looks like a symptom of faulty memory, rather than a typical memory error like use-after-free.
When you ran the unoptimized binary, the error appeared much earlier in the simulation, which is suspicious, because if it is a logic bug in Golly, I would expect it to trigger at around the same number of iterations (and it would take the unoptimized version much longer to get there). But if it's a hardware error, then a random bit flip might just happen every once in a while, regardless of how efficient the binary is.
So my first suggestion would be to run a diagnostic tool like memtest86+ to rule out faulty hardware. If that doesn't yield results, some other things to try:
0x4000000000or does it vary? If so, what values are possible?