Multi-thread: Random in AvalancheMC and AvalancheMicroscopic

[gabrielribcesario]

Hello,

@hschindl

@gabrielribcesario should I commit your fix to Medium.cc and Medium.hh? Or do you have a CERN gitlab account?

I do not have a CERN gitlab account and I don’t think I can have one, as I am not affiliated with CERN, so you’ll have to commit it. While we’re here, could you take a look into this post? I managed to find a solution for a problem I had about a month ago with neBEM. I had to edit my last answer since it’s been more than 14 days since the last post, so it probably did not trigger a notification. It is not a good solution since it increases the dependencies between Garfield and neBEM by requiring neBEM.h to be installed in Garfield’s INCLUDEDIR, and the CMakeLists.txt hints at a future decoupling of both modules.

@pigerard

Effectively, for Medium.cc and Medium.hh, changes are manly in commit 35639185. But seeing the changes, I don’t understand how they can modify the behavior.

@pigerard I see what you mean now. These changes did not fix/add a mutex to the base Medium class and a lock to the Medium::Init definition in Medium.cc, it’s only a refactoring of Medium*.hh header files.

@pigerard

[1184, 1209) 'name' (line 1146) <== Memory access at offset 1209 overflows this variable

Fortran strings are not null-terminated, and there is a call to a Fortran subroutine named Magboltz::gasmix_ in line 1567 causing the C-string char name[Magboltz::nCharName]; to not be null-terminated. This specific crash likely happens when the program tries to figure out the length of name in another portion of MediumMagboltz::Mixer. Right after the Magboltz::gasmix_ call, add:

name[Magboltz::nCharName-1] = '\0';

I don’t think this is the source of your original crash, so you should try triggering it again after the fix. @hschindl it might be a good idea to add the above modification to MediumMagboltz.cc and commit it along with Medium.cc and Medium.hh.