Warning: invalid memory pointer passed to a callee: geo->GetMasterVolume()->Draw();

Hello everyone,

I’m new to REST.
I’m trying to use one of the GDML file template presented at the REST-for-physics school of 01/2023.
Here is the template: https://github.com/rest-for-physics/rest-school/blob/master/day2/session2/box.gdml

In a restRoot -m 1 session, I run REST_Geant4_ViewGeometry("box.gdml") to visualise the geometry.
Everything works fine, I get the output output1.txt (1.3 KB)

But, in the same restRoot session, if I want to run this REST_Geant4_ViewGeometry command again, I get an error: output2.txt (2.7 KB)

I would say it is something that I don’t get concerning the way to use restRoot or even Root.

But the problem is more annoying than that: now, I’m trying to create my own geometry file, based on the box.gdml template, let’s say Mybox.gdml. And when I try to visualise the geometry in a new restRoot session, sometimes I get the error in output2.txt, even at first launch of the REST_Geant4_ViewGeometry command.
I don’t understand this error. I tried to look at the file


it didn’t help.

Thank you if you have an idea of what is happening.
If necessary, I could post Mybox.gdml.

I’m using
Root 6.24/06 (and Geant4 11.0.3) in a Conda environment.
REST v2.3.15
Linux Debian
The last output of git log in $REST_PATH: GitLog.txt (352 Bytes)

Thank you,

Ok, I can reproduce the problem with the box.rml example.

The problem is that the second time when the macro tries to create an instance using geo->GetMasterVolume(), the returned value is a null pointer (a non-valid memory address), and thus the line geo->GetMasterVolume()->Draw(); crashes.

I added a PR just to avoid reaching the seg.fault and output a more human error message.

If you got an account on GitHub you might approve yourself.


However, if you try your new geometry in a fresh ROOT session it should work. Perhaps there is something missing in the geometry file. Could you share your geometry files?

I added an issue also to keep in mind the problem of the second call.

Thank you for the support.

Here is the file
MyGeometry.gdml (3.4 KB)

So I confirm: the first time I launch REST_Geant4_ViewGeometry("MyGeometry.gdml") in a restRoot -m 1 session, I get the output2.txt
I run the REST_Geant4_ViewGeometry("MyGeometry.gdml") command a second time in the same restRoot session, and this time it works.

I also attached the full process here, I may have missed something.
error.txt (5.1 KB)

It works for me always in the first round.

My guess is that crashing first but not second is likely related to the ROOT version, I had bad experiences with ROOT 6.24.

We are using ROOT 6.26/10.

Of course, the second crash shouldn’t happen, this should be solved in our side.

For the geometry file, since your are not using gas mixtures, you may better use the materials.xml file instead of rest.xml.

Most of the materials are there, and new ones could be generated at GitHub - rest-for-physics/materials: A common repository to define materials that are later used at a GDML geometry. The materials are publicly accessible through the website https://rest-for-physics.github.io/materials/rest.xml. GDML files in REST can access directly that remote address. See also basic-geometries project. if possible I recommend we use common material definitions when using restG4.

Thanks for the advice for materials.xml. I’ll do that.

I wanted to use ROOT 6.26/10, but for whatever reason, Conda is not happy to contain Root 6.24/06 and Geant4 11.0.3 in the same environment. I may force it and see if it solves my problem. I will update about the result here.

Concerning the second crash with box.gdml:
[Let’s imagine this is solved on your side] if I want to work on the geometry file, can I just modify the box.gdml and run REST_Geant4_ViewGeometry("box.gdml") in the same restRoot session several times?

You may also try to use the instalROOT.sh script at

I think that in order to fix it we need to redesign that macro. Because I believe the problem is that we are re-using the pointer names for different objects. Thus, ROOT gets confused because it stores the keys in memory, but this I am not sure 100%.

It is true that it would be nice that the geometry would be updated as one modifies the file, perhaps @obis knows about.

But I usually work the calculations in the file then check that the geometry is what I expected, so I just relaunch the restRoot session again.

I don’t use the macro, just these lines that can be recovered from previous session with top-arrow.

TRestGDMLParser *g1 = new TRestGDMLParser();
TGeoManager *geo1 = g->GetGeoManager("box.gdml")

If you wish to draw a modified box.gdml file in the same session you could recover the previous commands taking care to replace the pointer names by new ones.

TRestGDMLParser *g2 = new TRestGDMLParser();
TGeoManager *geo2 = g->GetGeoManager("box.gdml")

It is the closest I find to what you want.

Ok I will try that thank you.

Concerning the REST_Geant4_ViewGeometry macro: I may have found something.
It turns out that when I run this macro in Root, I have in the output:
TRestGDMLParser: Creating temporary file at: "Mypath/.rest/gdml/PID58614_MyGeometry.gdml" for example.
I listed what is in this directory, and it turns out that it was full of previous PID<number>_<filename>.gdml created since I’m working on this geometry.
I erased everything, and now I don’t get the error anymore.
Could it be related to that?

That’s a temporary file that it is actually the final one that is given to the ROOT TGeoManager::Import method. The one we use in REST is translated to that temporary file, replacing env variables, or including a remote materials file, for example.

Thus, this file, the one at .rest/gdml/PID58614_MyGeometry.gdml can be open without REST libraries, just doing:

TGeoManager *geo = TGeoManager::Import(".rest/gdml/PID58614_MyGeometry.gdml");

But my believe is that there is something wrong with the ROOT TGeoManager class. I cannot find an explanation.

ok, thanks for the explanation.

Concerning the fact that the REST_Geant4_ViewGeometry macro crashes even at first try, some update: I have now a Conda environment with Root 6.26/10 (and Geant4 11.0.3).
I still have the same problem. Sometimes, I would have this crash (always with the same error message), and sometimes not, with no modification of the .gdml file between the 2 attempts.