this message means the program could not allocate memory and was killed by your system kernel. Are you particularly low on RAM when running these simulations? Because in your config I cannot spot anything that would require an unusually large amount of RAM.
One note though, your particle_type should probably be
particle_type = "proton"
instead, even though of course from a physics perspective the two should be equivalent.
If you manage to reproduce this, we could use the debugger gdb to find out where it comes from:
gdb --args allpix -c your_config.conf
$ catch throw bad_alloc
$ run
# ... runs, crashes and catches the exception
$ backtrace
# shows the back trace where the exceptions comes from
Concerning RAM… About 60 Gb was free at the moment of the simulation.
I guess particle_type is not a problem, because I’ve got the same error for “ion/2/4/0/0eV”
wow okay, with 60GB of RAM available this is a very odd behavior. May I ask which Allpix Squared, ROOT and Geant4 version you are using? If you also provide the geometry file (and models if necessary) I will see if I can reproduce this!
The debugging unfortunately didn’t work out and I don’t exactly understand why
I’m using root-6.22.02, geant-4.10.07p1 and allpix-squared-1.6.0. But, I as far as I remember, Allpix2 was recompiled several times with different Root and Geant4 versions, the problem was the same.
Geometry and models files are rather standard, I attached them.
with the help of your configuration files I was able to reproduce the issue and to obtain the stack trace shown below. Reading it carefully reveals that the program throws a bad_alloc exception when it is expected to allocate a vector with 3x10^11 entries - quite understandable that also your 60G of memory don’t provide that
It comes from a very late entry in a pulse, and I am still puzzled / investigation where this originates from. The time corresponds to something like 400s after the initial interaction in the corresponding event - and your integration_time is properly set to 40ns in the configuration, so we should not even see this.
I will continue to investigate and let you know once I have a better lead - or even: a fix for you.
In the mean time it might be worth considering moving to Allpix Squared 2.0, only minor changes to your configuration files should be necessary - if any at all.
All the best,
Simon
Backtrace:
Catchpoint 1 (exception thrown), 0x00007ffff0da57d2 in __cxa_throw ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) thread apply all bt full
Thread 1 (Thread 0x7fffed041180 (LWP 1249413) "allpix"):
#0 0x00007ffff0da57d2 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#1 0x00007ffff0d99641 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#2 0x00007ffff7f92c14 in __gnu_cxx::new_allocator<double>::allocate (__n=<optimized out>, this=<optimized out>) at /usr/include/c++/10/ext/new_allocator.h:115
__al = <optimized out>
#3 std::allocator_traits<std::allocator<double> >::allocate (__a=..., __n=<optimized out>) at /usr/include/c++/10/bits/alloc_traits.h:460
No locals.
#4 std::_Vector_base<double, std::allocator<double> >::_M_allocate (__n=<optimized out>, this=<optimized out>) at /usr/include/c++/10/bits/stl_vector.h:346
No locals.
#5 std::vector<double, std::allocator<double> >::_M_default_append (this=0x7fffffffc248, __n=399172664994) at /usr/include/c++/10/bits/vector.tcc:635
__len = <optimized out>
__new_start = <optimized out>
__size = 0
__navail = <optimized out>
#6 0x00007ffff230d722 in std::vector<double, std::allocator<double> >::resize (__new_size=399172664994, this=0x7fffffffc248) at /usr/include/c++/10/bits/stl_vector.h:940
No locals.
#7 allpix::Pulse::addCharge (this=this@entry=0x7fffffffc240, charge=<optimized out>, time=time@entry=3991726649.9340253) at /home/simonspa/software/allpix-squared/src/objects/Pulse.cpp:26
bin = 399172664993
#8 0x00007ffff7d50907 in allpix::PulseTransferModule::run (this=0x55555826a1d0, event_num=741) at /home/simonspa/software/allpix-squared/src/modules/PulseTransfer/PulseTransferModule.cpp:139
model = std::shared_ptr<allpix::DetectorModel> (use count 4, weak count 0) = {get() = 0x5555582695d0}
xpixel = 141
pixel_index = {fCoordinates = {fX = 141, fY = 137}}
pulse = {_vptr.Pulse = 0x7ffff2332710 <vtable for allpix::Pulse+16>, static fgIsA = {_M_b = {_M_p = 0x55555f898db0}, static is_always_lock_free = <optimized out>}, pulse_ = std::vector of length 0, capacity 0, bin_ = 0.01, initialized_ = true}
px = std::vector of length 0, capacity -577447673940515225
position = {fCoordinates = {fX = 7.7417448739270434, fY = 7.5115881659079635, fZ = 0.14959240173177868}}
ypixel = <optimized out>
pulses = std::map with 0 elements
[...]
this issue was actually fixed in v1.6.1, so the patch version directly following your currently used version (see: Generic/Tr). If your hesitant to move to v2.0.1 yes, I would strongly recommend to at least update to v1.6.2 which contains several bug fixes over v1.6.0 and is 100% backwards-compatible with it.
Please let me know if this fixes the problem for you. If there are still problems appearing with the updated version, don’t hesitate to come back to us!
see my post above, this has been fixed in v1.6.1, so a long time ago. Please use a recent release version. If it still occurs with a newer version it might be a different issue - then please provide us some details (allpix --version and the backtrace) so we can go hunting!
