Seg fault 11 when involving large number of configurations

[TheStarAlight]

When I'm trying to involve a large number of configurations to calculate DR coefficients of Xe¹⁰⁺, the segmentation fault 11 would occur when calling Structure.
I'm using julia's PyCall to invoke pfac. Here's an example of the configuration settings:

henmax = 9  # nmax of the he9_cfg
ainmax = 8   # nmax of the ai9_cfg
gnd9_cfg = "4p6 4d9"
exc9_cfg = OrderedDict(
    "Xe9_e_4f"   => "4p6 4d8 4f1",
    ["Xe9_e_5$l" => "4p6 4d8 5$(l)1" for l in L(0:4)]...,
    ["Xe9_e_6$l" => "4p6 4d8 6$(l)1" for l in L(0:5)]...,
    "Xe9_e_4p-4d"=> "4p5 4d10",
)
he9_cfg = OrderedDict(
    ["Xe9_he_$n$l"  => "4p6 4d8 $n$(l)1" for n in 7:henmax for l in L(0:n-1)]...,
     "Xe9_e_4p-4f"  => "4p5 4d9 4f1",
    ["Xe9_e_4p-5$l" => "4p5 4d9 5$(l)1" for l in L(0:4)]...,
    )   
ai9_cfg = OrderedDict(vcat(
    ["Xe9_a_4f2"    => "4p6 4d7 4f2"],
    ["Xe9_a_4f$n$l" => "4p6 4d7 4f1 $n$(l)1" for n in 5:ainmax for l in L(0:n-1)],
    ["Xe9_a_5p2"    => "4p6 4d7 5p2"],
    ["Xe9_a_5s5p"   => "4p6 4d7 5s1 5p1"],
    ["Xe9_a_5p5$l"  => "4p6 4d7 5p1 5$(l)1" for l in L([2,3,4])],
    ["Xe9_a_5p$n$l" => "4p6 4d7 5p1 $n$(l)1" for n in 6:ainmax for l in L(0:n-1)],
    ["Xe9_c_5s2"     => "4p6 4d7 5s2"],
    ["Xe9_c_5s5$l"   => "4p6 4d7 5s1 5$(l)1" for l in L(2:4)],
    ["Xe9_c_5s$n$l"  => "4p6 4d7 5s1 $n$(l)1" for n in 6:ainmax for l in L(0:n-1)],
    ["Xe9_c_5d2"     => "4p6 4d7 5d2"],
    ["Xe9_c_5d5$l"   => "4p6 4d7 5d1 5$(l)1" for l in L(3:4)],
    ["Xe9_c_5d$n$l"  => "4p6 4d7 5d1 $n$(l)1" for n in 6:ainmax for l in L(0:n-1)],
    ["Xe9_e_4p-$n$l" => "4p5 4d9 $n$(l)1" for n in 6:ainmax for l in L(0:n-1)]...,
))

Setting henmax, ainmax = 10,9 would lead to the following segfault (11) but 9,8 wouldn't:

[232430] signal 11 (1): Segmentation fault
in expression starting at /data/home/<user>/xenon/test.20260902.AI9+/Xe9+.en.jl:71
mmalloc at /data/home/<user>/.local/lib/python3.10/site-packages/pfac/fac.cpython-310-x86_64-linux-gnu.so (unknown line)
AllocHamMem at /data/home/<user>/.local/lib/python3.10/site-packages/pfac/fac.cpython-310-x86_64-linux-gnu.so (unknown line)
ConstructHamilton at /data/home/<user>/.local/lib/python3.10/site-packages/pfac/fac.cpython-310-x86_64-linux-gnu.so (unknown line)
SolveStructure at /data/home/<user>/.local/lib/python3.10/site-packages/pfac/fac.cpython-310-x86_64-linux-gnu.so (unknown line)
SolveStructure at /data/home/<user>/.local/lib/python3.10/site-packages/pfac/fac.cpython-310-x86_64-linux-gnu.so (unknown line)
PStructure at /data/home/<user>/.local/lib/python3.10/site-packages/pfac/fac.cpython-310-x86_64-linux-gnu.so (unknown line)
cfunction_call at /usr/local/src/conda/python-3.10.21/Objects/methodobject.c:552
_PyObject_Call at /usr/local/src/conda/python-3.10.21/Objects/call.c:305 [inlined]
PyObject_Call at /usr/local/src/conda/python-3.10.21/Objects/call.c:317
macro expansion at /data/home/<user>/.julia/packages/PyCall/1gn3u/src/exception.jl:108 [inlined]
#__pycall!##0 at /data/home/<user>/.julia/packages/PyCall/1gn3u/src/pyfncall.jl:43 [inlined]
disable_sigint at ./c.jl:167 [inlined]
__pycall! at /data/home/<user>/.julia/packages/PyCall/1gn3u/src/pyfncall.jl:42 [inlined]
_pycall! at /data/home/<user>/.julia/packages/PyCall/1gn3u/src/pyfncall.jl:29
_pycall! at /data/home/<user>/.julia/packages/PyCall/1gn3u/src/pyfncall.jl:11
unknown function (ip: 0x2ab6e055ff0d) at (unknown file)
#_#74 at /data/home/<user>/.julia/packages/PyCall/1gn3u/src/pyfncall.jl:86
jl_apply at /cache/build/builder-amdci5-4/julialang/julia-release-1-dot-12/src/julia.h:2391 [inlined]
jl_f__apply_iterate at /cache/build/builder-amdci5-4/julialang/julia-release-1-dot-12/src/builtins.c:868
PyObject at /data/home/<user>/.julia/packages/PyCall/1gn3u/src/pyfncall.jl:86
macro expansion at ./timing.jl:697 [inlined]
top-level scope at /data/home/<user>/xenon/test.20260902.AI9+/Xe9+.en.jl:353

I guess this might be resulted from the overflow of the Hamiltonian matrix size because it only happens for large configuration size but not large total memory occupation or out of memory error (on the server I have 178GB and only 30GB is used by FAC).
There's also a similar issue #816, perhaps we share the same problem.

Following the stacktrace, I found the relevant function:
structure.c
I'm not familar with the c language, but I decide to do a debug on the code and find out the problem.

[mfgu]

that's a good catch. although I am not sure such large calculations are practical. the zeroth order H matrix has more than 2 billion elements. diagonalization is already difficult at this size, and MBPT on it would take forever.