Re: really crazy crash

From: Tom Roberts <tjrob_at_fnal.gov>
Date: Wed, 23 Apr 2008 09:25:06 -0500


I thought that ".L file.C+" depends on the existence of a C++ compiler. I have many users who have no compiler, as they are physicists and have no use for C++.

How can I test for the ability to use the compiler? I have noticed that for large .root files the scan in my macro runs more slowly that I would like. So I could write a small macro that tests for C++ and then loads the real macro using it if present, or not.

Tom Roberts

Rene Brun wrote:

> Note that the recipe indicated by Lorenzo works everywhere, including 
> Windows.
> 
> Rene Brun
> 
> Tom Roberts wrote:

>> Lorenzo Moneta wrote:
>>> If you have a so long macro I recommend you first to compile it with
>>> AClic,
>>> do :
>>> .L test5.C+
>>> In this case the #includes must be there
>>
>> I distribute my macro to many users, most of whom are physicists, not
>> computer experts, and many of whom use Windows. I cannot depend on a
>> C++ compiler being installed on the user's system. So I don't want to
>> do this unless absolutely required.
>>
>> Axel has indicated he found this particular problem and has fixed it,
>> so I'll not change anything I'm doing, for now (though I will put in
>> all the #include-s). I still need to address the actual problem in my
>> big macro (related to TTreeFormula in some way I have not yet isolated
>> into a short test).
>>
>>
>> Tom Roberts
>>
>>
>>> Lorenzo
>>>
>>> On Apr 22, 2008, at 11:19 PM, Tom Roberts wrote:
>>>
>>>> I am trying to debug a >2000 line Root macro by isolating the
>>>> problem into a small macro (it works on 5.12-16 but crashes on
>>>> 5.18). I keep getting frustrated by seemingly trivial crashes that
>>>> do not seem to be the real problem. Here is another one that crashes
>>>> on 5.16 and 5.18 (Linux, Fedora Core 8).
>>>>
>>>>
>>>> I thought CINT permitted one to omit the #includes in a macro file.
>>>> This seems to not be the case, except for the remarkable fact that
>>>> it works, but crashes on ".q".
>>>>
>>>> Specifically: if I do:
>>>> .L test5.C
>>>> .q
>>>> root crashes.
>>>>
>>>> If I do:
>>>> .X test5.C
>>>> .q
>>>> it prints "Ntuple 'VirtualDetector/Det1' opened" (i.e. the macro
>>>> worked correctly) and then crashes on the .q.
>>>>
>>>> Indeed, all that is needed is a declaration "TNtuple *ntuple" in the
>>>> class to make this crash on .q.
>>>>
>>>> If I uncomment the #include, all is well. Note that no #include of
>>>> TFile.h seems to be needed, and attempts to display this problem
>>>> with TFile all failed.
>>>>
>>>> What is the difference between TFile and TNtuple?
>>>> Do I really need to #include the class header for every Root class I
>>>> use in a macro?
>>>> How does the macro execute correctly but crash on .q?
>>>>
>>>> (my big macro does crash on .q, but it normally calls
>>>> gApplication->Terminate(0) which does not crash, so this is not a
>>>> problem to my users.)
>>>>
>>>>
>>>> Tom Roberts
>>>> // test5.C
>>>>
>>>> //#include <TNtuple.h>
>>>>
>>>> class PlotNtuple {
>>>> TFile *file;
>>>> TNtuple *ntuple;
>>>> public:
>>>> PlotNtuple(const char *filename, const char *ntuplename);
>>>> void scan();
>>>> };
>>>>
>>>> PlotNtuple::PlotNtuple(const char *filename, const char *ntuplename)
>>>> {
>>>> file = 0;
>>>> ntuple = 0;
>>>>
>>>> file = new TFile(filename,"READ");
>>>> if(file->IsZombie()) {
>>>> printf("Cannot read '%s'\n",filename);
>>>> file = 0;
>>>> return;
>>>> }
>>>> ntuple = dynamic_cast<TNtuple*>(file->Get(ntuplename));
>>>> if(!ntuple) {
>>>> printf("Cannot find NTuple '%s'\n",ntuplename);
>>>> return;
>>>> }
>>>> printf("Ntuple '%s' opened\n",ntuplename);
>>>> }
>>>>
>>>> void PlotNtuple::scan()
>>>> {
>>>> }
>>>>
>>>>
>>>> void test5()
>>>> {
>>>> PlotNtuple *pn=new
>>>> PlotNtuple("g4beamline.root","VirtualDetector/Det1");
>>>> pn->scan();
>>>> }
>>>> <g4beamline.root>
>>>
>>

> Received on Wed Apr 23 2008 - 16:25:28 CEST

This archive was generated by hypermail 2.2.0 : Wed Apr 23 2008 - 17:50:02 CEST