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:
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== For counts of detected and suppressed errors, rerun with: -v
==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==
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== For counts of detected and suppressed errors, rerun with: -v
==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==
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 fileTGraph* 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