Re: Weird numbers when compiling macro

From: Florian Sittel <sittel_at_lettis.net>
Date: Wed, 22 Sep 2010 00:10:05 +0200


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==


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==


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
>>
Received on Wed Sep 22 2010 - 00:10:35 CEST

This archive was generated by hypermail 2.2.0 : Wed Sep 22 2010 - 11:50:02 CEST