Closed whit2333 closed 6 years ago
It works fine for me, both in interpreted and compiled mode.
I put your class definition in a separate file, which I include at the top of an existing replay script (the one from the Workshop2017 tutorial). It runs fine, happily printing out your "querty":
Starting analysis
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
SPP: event = 0, code = 0
qwerty
Warning::GenScaler:: (10,1) using default num 32 channels
SPP: event = 1, code = 0
qwerty
SPP: event = 2, code = 1
qwerty
SPP: event = 3, code = 1
qwerty
SPP: event = 4, code = 1
qwerty
SPP: event = 5, code = 1
qwerty
SPP: event = 6, code = 0
qwerty
SPP: event = 7, code = 1
qwerty
.....
(I modified the code slightly to print out the event number and analysis status code. It also works when just printing out "asdf" or whatever.)
I don't understand what you mean by "Podd's use of static
or the list of "post processes"". Do you mean the static_cast<THaPostProcess*>
? We could add a check to ensure that only objects inheriting from THaPostProcess
can be added to the list; that would be a good safety check. But the static_cast
is not the problem here; you class does inherit from the proper base class.
The only significant design flaw that one could argue about is that the return code of the Process
function is ignored by THaAnalyzer::PostProcess
, so PostProcess modules are currently not suitable as event filters for the standard ROOT file. But this is actually by design; the purpose of the PostProcess modules is that each module could open its own output file (whichever format) for writing event data (raw or somehow processed), using the analysis status code
as a hint. Or to serve event data up to the web, or similar things.
In any case, I don't know why your code crashes; maybe there's a different problem in your setup? How about compiling everything for debugging (scons -jN debug=1
) and running the analyzer under gdb
? That's usually the fastest way to the root cause of segfaults.
Possibly related analyzer commit:
commit 20cf746a6e78acef372711711b64f764bc144e28 Author: Ole Hansen ole@jlab.org Date: Mon Oct 2 18:05:44 2017 -0400
From Ed Brash: SCons fixes for interactive interpreter segfaults
...
- Add -fPIC to g++ command line flags specifically for the
compilation of src/main.C ... this was not done before, and
appears to have been the source of the segfault issue.
Closes #141
Like SCons, CMake does not add -fPIC to the compile options of src/main.cxx. I can readily reproduce the crash reported in JeffersonLab/analyzer#141 with your CMake build.
Yep. That fixed it. Thanks!
Below is my replay script. There is a segfault (see stacktrace below). I think this is likely a design flaw associated with the podd's use of
static
for the list of "post processes". If std::cout isn't used, then there is no problem.In addition to the class SimplePostProcess, the only other change from the source adopted from is adding the post process via