I am trying to implement secondary particle biasing by updating the parameters on my chosen G4ModularPhysics (i.e. G4EmPenelopePhysics). By doing so I can immediately observe the improvement in the number of hits in the phantom Sensitive Volume. However, after a few events pass, I receive a segmentation fault which I have attached in the post. The fault occurs irrespective of wether I am running the application in Serial or MT modes. I am inclined to think that it has something to do with the biasing for this modular physics as when I run the application without this it doesn’t raise the fault. Another possibility is that the fault might be highlighting some poor programming practice on my part which is only triggered when I run the application with biasing.
I tried exactly the-same simulation but using the G4EmLivermorePhysics and there are no issue. The application simulation runs to completion with no fault code.
I will kindly like to know if anyone is experiencing or has experienced same issues or has any suggestions.
Once you have a debuggable build, run in GDB and when it crashes you can see the line where it failed, inspect variable, look at the calling sequence to see if your code is involved somehow.
You raise an excellent suggestion. I didn’t build Geant4 or my application with debugging symbols (poor choice on my part).
I did go ahead and rebuild my Geant4 install with debbuging symbols. But then it turns out the gdb has changed quite a bit since I used it last. It now requires some Key Chain Access on Mac OS. If you have some experience with running GDB on the new .zsh shell for Mac, that would be helpful. Cheers.
Oh, you’re on a Mac; excellent choice. The stupid “key chain access” just means the first time in your terminal session, you need to put in your login password, so that the GDB/LLDB process can attach to your executable process. It’s annoying, but it’s a one time thing, so far as I have seen.
Thanks LOL. I have had the most luck building application in Geant4 using the Mac OS.
Spot on, with you advise I am able to get back into GDB. I tried to run the GDB debugger on my application using sudo gdb --args <my_executable> <my_executables_args> . It seems to start of but then it complains that the G4ENSDFSTATEDATA environment variable must be set. To me this simply sounds like the geant4.sh is not connected to the gdb process. I am certain that I have the geant4.sh sourced in .zsh. Please do you have any suggestions in this regards? I attached a screen shot of thegdbterminal taken just immediately after the run command for you to kindly verify my claims.
You shouldn’t need to run gdb under sudo. It should just give you the popup “authorization” box, and you enter your username and login password. Unless the good folks at Apple changed things again…
If you are running under sudo, that’s considered a new process, and you do need to source your geant4.sh again. Normally, the child would inherit your environment, but I think sudo is treated specially on most *nix system.
Finally, I am not a fan of sourcing configuration scripts in your shell setup. Especially not in the one that’s run for every child shell. Does Z-shell have something equivalent to “.login” or “.profile” or “.bash_profile”? Those are only executed at login time, and they’re safe for doing envvar setups. Otherwise, define yourself an alias, so you can just type “geant4” at the command line and get the setup done.
I am pretty certain that there are a few changes with GDB on the Mac OS. To set GDB up you would need to codesign it using the Keychain Access application on Mac . There are a few steps to making that work which I found after some Web search.
In any-case, I am able to get my application to run in the GDB environment but it still feels like something isn’t quite right. So when the segmentation fault is hit and I issue the backtrace command I get the result which I attached. What I was expecting is to be routed directly to the offending code (I think thats what I remember as the expected outcome). I am not sure what else to do besides try to test various portions of my code to narrow in on where the fault is.
The only other thing I observe which may be related to the fault is that I have a few of the warnings similar to the one below but related to exotic particles: G4VDecayChannel::FillDaughters() - [ mu+ ]1:nu_e is not defined !! The BR of this decay mode is set to zero.
Just to update the status of the issue I am having. So it seems like gdb wouldn’t work smoothly if you are using Mac (To be specific the Clang compiler). So if you been building your applications on Mac using Clang you might choose to opt for the lldb. lldb is an equivalent to gdb for clang. I didn’t know this until today because the last time I used gdb I was on the Ubuntu OS and running the g++ compiler. This might be of help to someone in future (of course if at all my assertion are correct).
Now regarding the SEG fault I was getting when biasing, It seems its generated in the PhysicsList and will occur wether in Serial or MT modes. It seems there is a NULL pointer on a defined particle but I don’t know how to address it. Please does anyone have a suggestion to handle this fault. I have attached the screenshot output from the lldb debugger. Thanks in advance.
I believe I found the issue. The way I had setup the physics initially was generating some particles with NULL pointers. So when I attempted to ActivateSecondayBiasing, it seemed to be unable to access the data in the memory location and throws the SEG fault. Once I defined each particle in my PhysicsList explicitly the application seems to be running fine and is almost 90% done (didn’t get past about 5% previously).
