Re: Weird numbers when compiling macro

Hi Florian,

are you fitting? Do you initialize the fit parameters? We can only guess if we don't at least see the content of messung3.C or even better have a stand-alone example (i.e. something we can run) that reproduces your problem.

Cheers, Axel.

Florian Sittel wrote on 09/22/2010 12:10 AM:
> Hi,
>
> thanks for the answer to such a late hour.
>
> I thought as well, I programmed some data leak.
> Therefore I rechecked my code a dozen of times - and could not find
> anything (which doesn't mean much, I guess).
> Never used valgrind before, good tip.
>
> The output gives:
>
>
> 1. run:
>
>
>
> valgrind --track-origins=yes root -b -q messung3.C+
> ==5539== Memcheck, a memory error detector
> ==5539== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
> ==5539== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
> ==5539== Command: root -b -q messung3.C+
> ==5539==
> *******************************************
> * *
> * W E L C O M E to R O O T *
> * *
> * Version 5.26/00d 24 August 2010 *
> * *
> * You are welcome to visit our Web site *
> * http://root.cern.ch *
> * *
> *******************************************
>
> ROOT 5.26/00d (tags/v5-26-00d_at_34963, Aug 24 2010, 13:30:22 on
> linuxx8664gcc)
>
> CINT/ROOT C/C++ Interpreter version 5.17.00, Dec 21, 2008
> Type ? for help. Commands must be C++ statements.
> Enclose multiple statements between { }.
> root [0]
> Processing messung3.C+...
> mes3_2_HM1508.csv 0.678808 +/-0.000605315 1.35762
> mes3_4_HM1508.csv 0.109316 +/-0.0546861 0.218631
> mes3_6_HM1508.csv 0.0859304 +/-0.0572224 0.171861
> mes3_7_HM1508.csv 1.75117 +/-0.042528 3.50234
> mes3_8_HM1508.csv 1.74871 +/-0.00111871 3.49742
> ==5539==
> ==5539== HEAP SUMMARY:
> ==5539== in use at exit: 0 bytes in 0 blocks
> ==5539== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==5539==
> ==5539== All heap blocks were freed -- no leaks are possible
> ==5539==
> ==5539== For counts of detected and suppressed errors, rerun with: -v
> ==5539== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 7)
>
>
>
>
> 2. run:
>
>
> valgrind --track-origins=yes root -b -q messung3.C+
> ==5548== Memcheck, a memory error detector
> ==5548== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
> ==5548== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
> ==5548== Command: root -b -q messung3.C+
> ==5548==
> *******************************************
> * *
> * W E L C O M E to R O O T *
> * *
> * Version 5.26/00d 24 August 2010 *
> * *
> * You are welcome to visit our Web site *
> * http://root.cern.ch *
> * *
> *******************************************
>
> ROOT 5.26/00d (tags/v5-26-00d_at_34963, Aug 24 2010, 13:30:22 on
> linuxx8664gcc)
>
> CINT/ROOT C/C++ Interpreter version 5.17.00, Dec 21, 2008
> Type ? for help. Commands must be C++ statements.
> Enclose multiple statements between { }.
> root [0]
> Processing messung3.C+...
> mes3_2_HM1508.csv 3.11056e+10 +/-3.4213e+10 6.22111e+10
> mes3_4_HM1508.csv 1.46738 +/-0.000653343 2.93476
> mes3_6_HM1508.csv 1.65165 +/-0.00108274 3.3033
> mes3_7_HM1508.csv 1.68977 +/-0.00129468 3.37955
> mes3_8_HM1508.csv 1.23635e+11 +/-9.37528e+10 2.4727e+11
> ==5548==
> ==5548== HEAP SUMMARY:
> ==5548== in use at exit: 0 bytes in 0 blocks
> ==5548== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==5548==
> ==5548== All heap blocks were freed -- no leaks are possible
> ==5548==
> ==5548== For counts of detected and suppressed errors, rerun with: -v
> ==5548== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 7)
>
>
>
>
> as far as I understand it, there should not be any memory leaks, but
> there are the faulty numbers again. One thing that bites me is the
> message "(suppressed: 7 from 7)" in the last line, but starting valgrind
> with --verbose option says
>
> --5512-- used_suppression: 4 dl-hack3-cond-1
> --5512-- used_suppression: 3 glibc-2.5.x-on-SUSE-10.2-(PPC)-2a
>
> which I interpret as messages not caused by my own code.
>
>
> perhaps it'll help posting some of the code, to show what the macros does:
>
> // this is the function, that generates one line of the above output.
> // it gets called 4 times
> void printStats( char* filename ){
> // the function graphFromCSV_2col builds a graph from a csv-file,
> // inside it does something like this:
> // TGraph* bufferGraph = new TGraph(...
> // ...some parsing code ...
> // return bufferGraph;
> // it gets called ones for every parsed file
> TGraph* graph = graphFromCSV_2col( filename, 1 );
>
> // get estimation for frequency
> Double_t freqEst = estimateFrequency( graph, 0 );
>
> // get minimum and maximum x-values
> Double_t xMin = graph->GetX()[0];
> Double_t xMax = graph->GetX()[ graph->GetN() -1 ];
>
> // use sinusoidal function to fit data
> TF1 *fitFcn = new TF1("fitFcn", sinusFit, xMin, xMax, 4);
> fitFcn->SetParameter(2, 2*TMath::Pi()* freqEst);
> fitFcn->SetParLimits(2, 2*TMath::Pi()* freqEst* 0.8, 2*TMath::Pi()*
> freqEst* 1.2 );
>
> // fit function to graph
> graph->Fit( fitFcn, "Q" );
>
> Double_t amp = TMath::Abs( fitFcn->GetParameter(1) );
> cout << filename << "\t" << amp << " +/-" << fitFcn->GetParError(1)
> << "\t\t" << 2*amp << endl;
> }
>
>
> I hope this clearifies it a bit...
>
>
>
>
> On 21.09.2010 23:41, Philippe Canal wrote:

>> Hi Florian,
>>
>> Most likely you have uninitialized memory in your code (the result is
>> hence random,
>> including possibly the correct result).
>>
>> Running:
>>
>> valgrind --track-origins=yes root.exe -b -l -q messung3.C+
>>
>> Is likely to show you exactly what memory is not initialized.
>>
>> Cheers,
>> Philippe.
>>
>> On 9/21/10 2:33 PM, Florian Sittel wrote:
>>> Hello fellow ROOT-users and developers,
>>>
>>> I am new to ROOT and I hope this is the right place to ask this
>>> question:
>>>
>>> I wrote some little macros to process some data. In short, I produce
>>> several graphs from different csv-files and fit a sinusoidal function
>>> to them. Nothing special here.
>>> The macros run OK when running through CINT.
>>> The output is as follows (numbers are amplitudes of sinusoidal fit,
>>> the last numbers are just 2*amplitudes):
>>>
>>> # root messung3.C
>>> root [0]
>>> Processing messung3.C...
>>> mes3_2_HM1508.csv 0.678808 +/-0.000605315 1.35762
>>> mes3_4_HM1508.csv 1.46738 +/-0.000653343 2.93476
>>> mes3_6_HM1508.csv 1.65165 +/-0.00108274 3.3033
>>> mes3_7_HM1508.csv 1.68977 +/-0.00129468 3.37955
>>> mes3_8_HM1508.csv 1.74871 +/-0.00111871 3.49742
>>> root [1] .q
>>> root -l messung3.C 12,15s user 0,08s system 85% cpu 14,282 total
>>>
>>>
>>> These numbers seem to be correct.
>>>
>>>
>>>
>>>
>>> Anyway, if I compile the macro and run it, I get random numbers:
>>>
>>>
>>> first run:
>>>
>>> # root messung3.C++
>>> root [0]
>>> Processing messung3.C++...
>>> Info in <TUnixSystem::ACLiC>: creating shared library
>>> /somePath/./messung3_C.so
>>> mes3_2_HM1508.csv 2684.47 +/-2508.35 5368.95
>>> mes3_4_HM1508.csv 1142.86 +/-14.5639 2285.71
>>> mes3_6_HM1508.csv 2493.13 +/-1758.83 4986.25
>>> mes3_7_HM1508.csv 2465.53 +/-55480.5 4931.06
>>> mes3_8_HM1508.csv 1.74871 +/-0.00111871 3.49742
>>> root [1] .q
>>>
>>>
>>> second run:
>>>
>>> # root messung3.C++
>>> root [0]
>>> Processing messung3.C++...
>>> Info in <TUnixSystem::ACLiC>: creating shared library
>>> /somePath/./messung3_C.so
>>> mes3_2_HM1508.csv 0 +/-7.69996e+31 0
>>> mes3_4_HM1508.csv 0 +/-7.69996e+31 0
>>> mes3_6_HM1508.csv 0 +/-7.69996e+31 0
>>> mes3_7_HM1508.csv 0 +/-7.69996e+31 0
>>> mes3_8_HM1508.csv 1.74871 +/-0.00111871 3.49742
>>>
>>>
>>> third run:
>>>
>>> # root messung3.C++
>>> root [0]
>>> Processing messung3.C++...
>>> Info in <TUnixSystem::ACLiC>: creating shared library
>>> /somePath/./messung3_C.so
>>> mes3_2_HM1508.csv 0.678808 +/-0.000605315 1.35762
>>> mes3_4_HM1508.csv 1.46738 +/-0.000653343 2.93476
>>> mes3_6_HM1508.csv 1.65165 +/-0.00108274 3.3033
>>> mes3_7_HM1508.csv 1.68977 +/-0.00129468 3.37955
>>> mes3_8_HM1508.csv 7.62246e+11 +/-2.00788e+13 1.52449e+12
>>>
>>>
>>>
>>> Interestingly, sometimes some numbers are correct, while during the
>>> same run, others get messed up.
>>>
>>> I thought, maybe ROOT doesn't reset memory properly, so I added a
>>> gROOT->Reset() before every single graph-generation and fit.
>>> No change here.
>>> Even when I quit ROOT and re-run it the data gets messed up.
>>>
>>>
>>> The code is a bit complex to post here, but I hope there is somebody,
>>> who has experienced a similar problem before. Perhaps it is just some
>>> trivial setting.
>>>
>>>
>>> Thanks in advance,
>>> Florian
>>>