[ROOT] Interpreting valgrind info

RE: [ROOT] Interpreting valgrind info

Re: [ROOT] Interpreting valgrind info

Hi,

Valgrind is only going to hlpe if you can run your program without
crashing. If that's the case, run it on root.exe, not root (yes, also on
Linux).

You can run valgrind --tool=massif to see where the memory goes. I
recommend to use massif-visualizer (use Google to find ts current
location) to analyze its report.

Cheers, Axel.

On 06/01/2012 09:52 AM, Harinder Singh Bawa wrote:
> Hello,
> 
> I am running Root code!
> I am getting memory leakage problem in my code which runs for sometime and then crash with the following error:
> 
> *********************************************
> Error: Symbol #include is not defined in current scope  (tmpfile):1:
> Error: Symbol exception is not defined in current scope  (tmpfile):1:
> Syntax Error: #include <exception> (tmpfile):1:
> Error: Symbol G__exception is not defined in current scope  (tmpfile):1:
> Error: type G__exception not defined FILE:(tmpfile) LINE:1
> (Long64_t)0
> ***** Interpreter error recovered *****
> 
> **************************************************
> 
> 
> I was suggested to run valgrind and below is the result: Can anybody suggest how to interpret valgrind.
What is this suggesting towards!!!
> 
> 
> 
> Val grind info:
> ====================
> --3044 <tel:3044>-- REDIR: 0x6f01c00 (operator delete(void*)) redirected to 0x4c701af (operator delete(void*))
> ==3044 <tel:3044>== 
> ==3044 <tel:3044>== HEAP SUMMARY:
> ==3044 <tel:3044>==     in use at exit: 88 bytes in 1 blocks
> 
> 
> ==3044 <tel:3044>==   total heap usage: 3 allocs, 2 frees, 276 bytes allocated
> ==3044 <tel:3044>== 
> ==3044 <tel:3044>== Searching for pointers to 1 not-freed blocks
> 
> 
> 
> ==3044 <tel:3044>== Checked 201,536 bytes
> ==3044 <tel:3044>== 
> ==3044 <tel:3044>== 88 bytes in 1 blocks are still reachable in loss record 1 of 1
> 
> 
> ==3044 <tel:3044>==    at 0x4C70D2D: operator new[](unsigned int) (vg_replace_malloc.c:258)
> ==3044 <tel:3044>==    by 0x8049FBA: main (in /nfs/t3nfs/share/atlas/
> 
> ATLASLocalRootBase/x86_64/root/5.28.00-slc5-gcc4.3-i686/bin/root)
> ==3044 <tel:3044>==
> ==3044 <tel:3044>== LEAK SUMMARY:
> ==3044 <tel:3044>==    definitely lost: 0 bytes in 0 blocks
> ==3044 <tel:3044>==    indirectly lost: 0 bytes in 0 blocks
> ==3044 <tel:3044>==      possibly lost: 0 bytes in 0 blocks
> ==3044 <tel:3044>==    still reachable: 88 bytes in 1 blocks
> ==3044 <tel:3044>==         suppressed: 0 bytes in 0 blocks
> ==3044 <tel:3044>==
> ==3044 <tel:3044>== ERROR SUMMARY: 0 errors from 0 contexts (suppressed:
> 30 from 9)
> --3044 <tel:3044>--
> --3044 <tel:3044>-- used_suppression:     30 dl-hack3
> ==3044 <tel:3044>==
> ==3044 <tel:3044>== ERROR SUMMARY: 0 errors from 0 contexts (suppressed:
> 30 from 9)
> 
> *******************************************************************************************************
> 
> 
> Harinder
> 
> 

Re: [ROOT] Histogram mean

Hi Rooters,

I am having trouble with |TMatrixDEigen| for larger matrices. I have made 
200x200 matrices of correltions which I'm trying to digagonalize. It 
mostly works, but sometimes fails with

root [13] TMatrixDEigen emat(*scanMatrix)
Error in <MakeSchurr>: too many iterations

It apparently thinks the matrix is too close to singular.

However, I can still find diagonalilzed variables with ugly, homemade 
Gram-Schmidt (which I'm trying to replace with something better).

The matrix that gives trouble has in fact smaller correlations than some 
of the ones that work successfully.

So what's going on here? And how do I fix it? Do I have to move beyond 
root?

-AE

A.E. Snyder, The Former Group C (TFC)        \!c*p?/
SLAC Mail Stop #95                          ((.   .))
Box 4349                                        |
Stanford, Ca, USA, 94309                      '\|/`
e-mail:snyder <at> slac.stanford.edu                 o
phone:650-926-2701                              _
http://www.slac.stanford.edu/~snyder          BaBar
FAX:707-313-0250                          Collaboration
                                                 &
                                            Fermi/GLAST

[ROOT] Subject correction -- should be "TMatrixDEigen problems"

On Fri, 1 Jun 2012, Arthur E. Snyder wrote:

> Hi Rooters,
>
> I am having trouble with |TMatrixDEigen| for larger matrices. I have made
> 200x200 matrices of correltions which I'm trying to digagonalize. It
> mostly works, but sometimes fails with
>
> root [13] TMatrixDEigen emat(*scanMatrix)
> Error in <MakeSchurr>: too many iterations
>
> It apparently thinks the matrix is too close to singular.
>
> However, I can still find diagonalilzed variables with ugly, homemade
> Gram-Schmidt (which I'm trying to replace with something better).
>
> The matrix that gives trouble has in fact smaller correlations than some
> of the ones that work successfully.
>
> So what's going on here? And how do I fix it? Do I have to move beyond
> root?
>
> -AE
>
>
>
>
>
>
>
> A.E. Snyder, The Former Group C (TFC)        \!c*p?/
> SLAC Mail Stop #95                          ((.   .))
> Box 4349                                        |
> Stanford, Ca, USA, 94309                      '\|/`
> e-mail:snyder <at> slac.stanford.edu                 o
> phone:650-926-2701                              _
> http://www.slac.stanford.edu/~snyder          BaBar
> FAX:707-313-0250                          Collaboration
>                                                 &
>                                            Fermi/GLAST
>
>
>
>

[ROOT] RootMpi Report

[ROOT]

Hi everybody,

I just discovered the „candle“-draw option. Very nice. But when I’m trying

t->Draw("a:b","","candle")

I will get two candles with the whole distributions of “a” and “b”, What I
actually want are candles of “a” differentiated by all subtypes of “b”.
Something like

t->Draw("a{b==1}:a{b==2}:a{b==3}","","candle")

I thought as the common “a:b” draw-option shows a TH2 of what I actually
want it would be possible to show it that way. I could also cast it from
TH2. Is there a way?

Georg

Re: [ROOT]

> t->Draw("a{b==1}:a{b==2}:a{b==3}","","candle")

You can do that already . may be just making 3 function doing the selection.
Then you plot the 3 functions. 
(f1:f2:f3…)

On Jun 4, 2012, at 8:57 AM, Georg Troska wrote:

> Hi everybody,
> 
> I just discovered the "candle"-draw option. Very nice. But when I'm trying
> 
> t->Draw("a:b","","candle")
> 
> I will get two candles with the whole distributions of "a" and "b", What I
> actually want are candles of "a" differentiated by all subtypes of "b".
> Something like
> 
> t->Draw("a{b==1}:a{b==2}:a{b==3}","","candle")
> 
> I thought as the common "a:b" draw-option shows a TH2 of what I actually
> want it would be possible to show it that way. I could also cast it from
> TH2. Is there a way?
> 
> Georg
> 
> 

[ROOT] Compiling ROOT as 32bit on a 64 bit Maschine

Hello,

I have some Problem compiling ROOT as a 32bit executable in an 64 bit
environment.
Our system uses the module environment(http://modules.sourceforge.net/)
to give the users the possibility to select between different versions
of software (eg. gcc) and libraries. There are 32bit and 64 bit versions
installed in the system.
This works for most of the software, but not for example the
libungif.so, which is installed in /usr/lib (64bit version). But if I
select the 32bit Version installed via module environment, the ROOT
configure script still uses the version from /usr/lib.
Is there a way to work around such a problem?

Regards,

Jörn Wüstenfeld

Re: [ROOT] Compiling ROOT as 32bit on a 64 bit Maschine

Latest version of ROOT always uses the built in version of ungif. Check the configure flags to select built
in version. 

Cheers, Fons.

On 6 Jun 2012, at 11:27, Joern Wuestenfeld <j.wuestenfeld <at> gsi.de> wrote:

> Hello,
> 
> I have some Problem compiling ROOT as a 32bit executable in an 64 bit
> environment.
> Our system uses the module environment(http://modules.sourceforge.net/)
> to give the users the possibility to select between different versions
> of software (eg. gcc) and libraries. There are 32bit and 64 bit versions
> installed in the system.
> This works for most of the software, but not for example the
> libungif.so, which is installed in /usr/lib (64bit version). But if I
> select the 32bit Version installed via module environment, the ROOT
> configure script still uses the version from /usr/lib.
> Is there a way to work around such a problem?
> 
> Regards,
> 
> Jörn Wüstenfeld
>