@ksmith So, I guess this problem has been solved, right? Could you please mark @sbinet’s comment as solution? Thanks!
That’s not a solution.
I just explained why in some setup you get garbled data.
python shouldn’t let you get (silently!) garbled data.
in C++, when you don’t give the correct types to a function/method, the first line of defense (the compiler) will tell you, loudly.
in python calling C++, the method dispatcher should tell you. right now, it doesn’t.
1 Like
also, AFAIK, the original segfault still happens when the snippet of code is executed inside a function.
that’s another bug 
I agree with @sbinet although he has proposed a possible avoidance of one issue, I would not call it solved. (He has clarified the cause nicely though it seems.) In addition, the original issue hasn’t been resolved although @Graipher’s suggestion to not use a method would be another work around.
Dear @ksmith,
Apologies for the delay. I discussed the matter with other members of the team and created a JIRA issue (ROOT-9040) to address this problem.
For now, I recommend just setting the proper types for the vectors you pass as pointers to ROOT in Python, and add input() to get a pause for user input before exiting. I believe the cause of the crash could be an issue at tear down rather than being related to the problem that vector types are mismatched.
Cheers,
—Guilherme
Thanks for the investigation. I selected to watch the bug. I will definitely try to use “proper” types although this seems to go against the python ideology. As for adding input() this is not always a reasonable solution as some scripts were designed to be run automatically with no user interaction. At the moment we are avoiding the TMultiGraph::GetListOfGraphs method as that seems to be involved.
I ran into the issue of “proper” types again and had to reteach myself what was learned above. I wanted to clarify the situation for myself and others who might run into this. At the moment the dtype of the two numpy arrays passed to TGraph must match. In addition, only certain dtype values produce reasonable output:
| Type | Constructor Chosen | Output |
|---|---|---|
| int32 | int* | Good |
| int64 | double* | Bad |
| float32 | int* | Bad |
| float64 | double* | Good |
* The constructor chosen may not be correct, but is an educated guess based on above discussions.
Therefore the default type for integer arrays on 64-bit machine (int64) will not produce reasonable output.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.