Exit code -9 when running simulation

User Support
21

It’s worth considering. Can you do an ldd on your openmc executable and send the output here?

22

I originally sent this only to Paul and not the whole thread.

ldd $(which openmc)
linux-vdso.so.1 (0x00007fffaa1f7000)
libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00002b13b173e000)
libm.so.6 => /usr/lib/libm.so.6 (0x00002b13b1a65000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00002b13b1d6a000)
libquadmath.so.0 => /usr/lib/libquadmath.so.0 (0x00002b13b1f80000)
libc.so.6 => /usr/lib/libc.so.6 (0x00002b13b21bd000)
/lib64/ld-linux-x86-64.so.2 (0x00002b13b151a000)

23

Hi John, Paul,

I have the same ldd.

Be Well
Anthony

24

Ok, I managed to get rid of the segfault. But I’m not sure what I did is legit.

On line 1839 of tally.F90, in subroutine get_scoring_bins, we have the following code:

case (FILTER_MATERIAL)
matching_bins(i) = get_next_bin(FILTER_MATERIAL, &
p % material, i_tally)

When we call this with p % material = -1, which seems to indicate a void material, we end up with filter_value = -1 in line 2247:

n = size(tally_maps(filter_type) % items(filter_value) % elements)

Which then segfaults because we’re trying to index by -1.

So what I’ve done is wrap that get_next_bin call in an if statement:

case (FILTER_MATERIAL)
if (p % material /= MATERIAL_VOID) then
matching_bins(i) = get_next_bin(FILTER_MATERIAL, &
p % material, i_tally)
endif

This gets rid of this segfault on my machine. Am I committing any egregious crimes against physics? Or is this OK?

John

25

No egregious crimes with that fix at all; that’s exactly what I would have done. I finally reproduced the error too – not sure why I wasn’t getting it before. Do you want to submit a PR fixing this? I could do it myself, but then I need someone else to review it. If you submit, I can review it.

Thanks!!