Cannot run the TrackDegrade example

Garfield++
1

Hello,

Pretty much what the title says: I can’t run the TrackDegrade related examples (mip.C and plotdedx.C). Whenever I try to run them I get the following stack trace:

image
image1403×199 7.78 KB

Any help is appreciated.

Sincerely,

Gabriel

2

Maybe @hschindl can help

3

Hi,
sorry for the late reply. Unfortunately I didn’t manage to reproduce this issue; both on my laptop (macOS) and on lxplus (RHEL9) the examples run ok. What platform are you using?

4

Hello,

No problem!

I am running Ubuntu-22.04 on WSL.

5

Hi,
I seem to remember that there was an issue with the memory limit on WSL some time ago. Can you check what’s the max. stack size (ulimit -s) and try increasing it (or setting it to unlimited)?

6

Maybe I am doing something wrong, but I could not set the stack size to unlimited. I did manage to increase it from 8192 to 65533 (both Soft and Hard limits are unlimited). The output is still the same:

gabrielribcesario@:~/garfieldpp/Examples/Degrade/build$ ./mip
MediumMagboltz::SetComposition: Ar/CO2 (90/10)

 *** Break *** segmentation violation
 Generating stack trace...
 0x00007ee97810af74 in Garfield::TrackDegrade::Initialise(Garfield::Medium*, bool) + 0x7ee from /home/gabrielribcesario/garfieldpp/install/lib/libGarfield.so.0.3
 0x000057bca88f3c8a in <unknown> from ./mip
 0x00007ee976229d90 in <unknown> from /lib/x86_64-linux-gnu/libc.so.6
 0x00007ee976229e40 in __libc_start_main + 0x80 from /lib/x86_64-linux-gnu/libc.so.6
 0x000057bca88f3725 in <unknown> from ./mip

ulimit output:

gabrielribcesario@:~/garfieldpp/Examples/Degrade/build$ ulimit -S
unlimited
gabrielribcesario@:~/garfieldpp/Examples/Degrade/build$ ulimit -H
unlimited
gabrielribcesario@:~/garfieldpp/Examples/Degrade/build$ ulimit -s
65533
7

Hello,

Today I was able to get my hands on a native Linux machine and run the Degrade example again. The Linux distribution of the machine is Ubuntu 22.04, which is the same platform I was using on WSL. I built both Garfield++ and ROOT 6.36.00 as usual and tried running the Degrade example. I still got an error, which means that the problem (probably) didn’t come from WSL. This was the stack trace I got:

 *** Break *** segmentation violation



===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
#0  0x00007b9d1f8ea3ea in __GI___wait4 (pid=8856, stat_loc=stat_loc
entry=0x7ffd79387298, options=options
entry=0, usage=usage
entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30
#1  0x00007b9d1f8ea3ab in __GI___waitpid (pid=<optimized out>, stat_loc=stat_loc
entry=0x7ffd79387298, options=options
entry=0) at ./posix/waitpid.c:38
#2  0x00007b9d1f850bdb in do_system (line=<optimized out>) at ../sysdeps/posix/system.c:171
#3  0x00007b9d20314a96 in TUnixSystem::StackTrace() () from /home/gabriel/root/lib/libCore.so
#4  0x00007b9d20311d75 in TUnixSystem::DispatchSignals(ESignals) () from /home/gabriel/root/lib/libCore.so
#5  <signal handler called>
#6  0x00007b9c7190a085 in __degrad_MOD_mixer () from /home/gabriel/garfieldpp/install/lib/libDegrade.so.3
#7  0x00007b9c7191dd43 in deginit () from /home/gabriel/garfieldpp/install/lib/libDegrade.so.3
#8  0x00007b9d2170b0c4 in Garfield::TrackDegrade::Initialise(Garfield::Medium*, bool) () from /home/gabriel/garfieldpp/install/lib/libGarfield.so.0.3
#9  0x00005bc6ee420c8a in main ()
===========================================================


The lines below might hint at the cause of the crash. If you see question
marks as part of the stack trace, try to recompile with debugging information
enabled and export CLING_DEBUG=1 environment variable before running.
You may get help by asking at the ROOT forum https://root.cern/forum
preferably using the command (.forum bug) in the ROOT prompt.
Only if you are really convinced it is a bug in ROOT then please submit a
report at https://root.cern/bugs or (preferably) using the command (.gh bug) in
the ROOT prompt. Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#6  0x00007b9c7190a085 in __degrad_MOD_mixer () from /home/gabriel/garfieldpp/install/lib/libDegrade.so.3
#7  0x00007b9c7191dd43 in deginit () from /home/gabriel/garfieldpp/install/lib/libDegrade.so.3
#8  0x00007b9d2170b0c4 in Garfield::TrackDegrade::Initialise(Garfield::Medium*, bool) () from /home/gabriel/garfieldpp/install/lib/libGarfield.so.0.3
#9  0x00005bc6ee420c8a in main ()
===========================================================
8

I can confirm. Running mip and plotdedx examples on my Ubuntu 22.04 LTS virtual machine I obtain segmentation violations that points towards TrackDegrade::Initialize.

9

Ok, thanks both! I will try to reproduce and debug…

10

What compilers are you using?

11

I am using the GNU Compiler Collection (gfortran, gcc, g++) with version 11.4.0.

12

Hello,

The problem probably comes from the COMMON blocks in the degrad.f file, causing every value defined in the SETUP subroutine to default to 0 in every other part of the program.

I tried looking something up and found this:

In the post user eriktous shows this piece of documentation of the Fortran 77 standard:

17.3 Events That Cause Entities to Become Undefined
[…]
6. The execution of a RETURN statement or an END statement within a subprogram causes all entities within the subprogram to become undefined except for the following:
[…]
d. Entities in a named common block that appears in the subprogram and appears in at least one other program unit that is either directly or indirectly referencing the subprogram

I decided to test this with the COMMON/INPT/ block. Only by changing /INPT/ to an unnamed block (COMMON/INPT/ to COMMON//) the program was able to preserve the values of the variables NGAS,NSTEP,NANISO,EFINAL,ESTEP,AKT,ARY,TEMPC,TORR,IPEN from SETUP to MIXER. For some reason SAVE isn’t implied for the named block even though the it has been declared in other subroutines, and using SAVE/INPT/ doesn’t work either.

13

Thanks a lot! Interesting… So changing COMMON/INPT/ to COMMON// everywhere in degrad.f fixes the problem (or provides a workaround)?

14

Well, it provides a workaround for the /INPT/ block only, others blocks are still being affected by this issue so I still get segmentation errors due the NaN propagation that follows from the division by zero.

A few PRINT *, statements in the DEGINIT subroutine later and I think that the actual problem is originating in the DENSITY subroutine, but I haven’t had the time to look into it yet.