FindFullPathName question

Pepe_Le_Pew · March 30, 2011, 11:32am

VIVE L’AMOUR!
some recent discussions [url]Problem with Reading Root File and [url]Draw the 2-D histograms which in the subFolder triggered my next dump question (the “run.root” file comes from the latter discussion).

root [0] TFile file = new TFile(“run.root”, “READ”);
root [1] TFolder histos = (TFolder)(file->FindObjectAny(“histos”));
root [2] histos->FindFullPathName(“shDsssdE”)
(const char 0xb77d6980)"//histos/singles/shDsssdE"
root [3] file->GetPath()
(const char* 0x98a6948)"run.root:/"
root [4] gDirectory->GetPath()
(const char* 0x98a6948)"run.root:/"
root [5] gROOT->GetPath()
(const char* 0x9674d10)“Rint:/”

What is the value returned by the “FindFullPathName” good for?
I can’t seem to be able to Find/Get the object that it points to (using this “full path name” string).

A pitiful case, am I not?
Pepe Le Pew.

pcanal · March 30, 2011, 8:00pm

Hi,

It can be used in TFolder::FindObject. The TDirectory and the TFolder universes are completely separate (albeit with ‘similar’ concepts in play).

Philippe.

Pepe_Le_Pew · March 30, 2011, 8:08pm

Well, it seems I miss something …

root [3] histos->FindObject("//histos/singles/shDsssdE")
(const class TObject*)0x0
root [4] histos->FindObjectAny("//histos/singles/shDsssdE")
(const class TObject*)0x0

pcanal · March 30, 2011, 8:20pm

Humm, indeed.

For the full path name lookup to work, the containing folder must be added explicitly to the ‘RootFolder’:gROOT->GetRootFolder()->Add(myfolder);and the result returns by FullPathName is currently incorrect as it lacks root/ after the first //

Cheers,
Philippe.

Pepe_Le_Pew · March 30, 2011, 8:32pm

O.K. I start to get something that’s working …

root [2] histos->FindObject("//root/histos/singles/shDsssdE")
(const class TObject*)0x0
root [3] histos->FindObjectAny("//root/histos/singles/shDsssdE")
(const class TObject*)0x0
root [4] gROOT->GetRootFolder()->Add(histos)
root [5] histos->FindObject("//root/histos/singles/shDsssdE")
(const class TObject*)0x9bbd420
root [6] histos->FindObjectAny("//root/histos/singles/shDsssdE")
(const class TObject*)0x9bbd420

I assume now that I always need to manually “Add” my “top level” folder to the “RootFolder”.
Why do I get an improper “FullPathName” (i.e. “//” instead of “//root/”)?

pcanal · March 30, 2011, 8:46pm

Hi,

[quote]Why do I get an improper “FullPathName” (i.e. “//” instead of “//root/”)?[/quote]Because of a deficiency corrected in revision 38679 of the trunk (i.e. fixed thanks to your input ).

Cheers,
Philippe.

Pepe_Le_Pew · March 30, 2011, 8:53pm

I’ve found that I can “cut” the whole “//root” string …

root [8] gROOT->FindObject("//root/histos/singles/shDsssdE")
(const class TObject*)0x82e2410
root [7] gROOT->FindObjectAny("//root/histos/singles/shDsssdE")
(const class TObject*)0x82e2410

and also …

root [4] gROOT->FindObject("/histos/singles/shDsssdE")
(const class TObject*)0x82e2410
root [6] gROOT->FindObjectAny("/histos/singles/shDsssdE")
(const class TObject*)0x82e2410

and also …

root [10] histos->FindObject("/histos/singles/shDsssdE")
(const class TObject*)0x82e2410
root [9] histos->FindObjectAny("/histos/singles/shDsssdE")
(const class TObject*)0x82e2410

Pepe_Le_Pew · March 30, 2011, 9:11pm

Following my previous post here, maybe the “FindFullPathName” should return a “relative path” (i.e. starting with one “/” instead of “//root”).

Sorry, another bug found …

root [0] TFile *file = new TFile(“run.root”, “READ”);
root [1] TFolder histos = (TFolder)(file->FindObjectAny(“histos”));
root [2] gROOT->GetRootFolder()->Add(histos)
root [3] gROOT->GetRootFolder()->FindFullPathName(“shDsssdE”)

*** Break *** segmentation violation

pcanal · March 30, 2011, 9:18pm

Hi,

I can not reproduce the segmentation fault.

Cheers,
Philippe.

Pepe_Le_Pew · March 30, 2011, 9:23pm

I have here ROOT 5.28/00b “Checked out revision 38672” (just several hours ago today).
It’s Ubuntu 10.04.2 LTS, i686, gcc 4.4.3.

In the meantime, I’ve found that with “gROOT” it works even without the leading “/” …

root [3] gROOT->FindObject(“histos/singles/shDsssdE”)
(const class TObject*)0x875d3f8
root [4] gROOT->FindObjectAny(“histos/singles/shDsssdE”)
(const class TObject*)0x875d3f8

but not here:

root [5] histos->FindObject(“histos/singles/shDsssdE”)
(const class TObject*)0x0
root [6] histos->FindObjectAny(“histos/singles/shDsssdE”)
(const class TObject*)0x0

So, maybe the leading “/” would really be correct (instead of “//root”).

Pepe_Le_Pew · March 30, 2011, 9:25pm

Here’s the full dump … if it is of any use for you …

> root
  *******************************************
  *                                         *
  *        W E L C O M E  to  R O O T       *
  *                                         *
  *   Version  5.28/00b     14 March 2011   *
  *                                         *
  *  You are welcome to visit our Web site  *
  *          http://root.cern.ch            *
  *                                         *
  *******************************************

ROOT 5.28/00b (branches/v5-28-00-patches@38394, Mar 30 2011, 16:55:00 on linux)

CINT/ROOT C/C++ Interpreter version 5.18.00, July 2, 2010
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
root [0] TFile *file = new TFile("run.root", "READ");
root [1] TFolder *histos = (TFolder*)(file->FindObjectAny("histos"));
root [2] gROOT->GetRootFolder()->Add(histos)
root [3] gROOT->GetRootFolder()->FindFullPathName("shDsssdE")

 *** Break *** segmentation violation



===========================================================
There was a crash (#7 0xb730e91d in SigHandler(ESignals) ()).
This is the entire stack trace of all threads:
===========================================================
#0  0xb783d430 in __kernel_vsyscall ()
#1  0xb66bb7d3 in __waitpid_nocancel ()
    at ../sysdeps/unix/syscall-template.S:82
#2  0xb665cde3 in do_system (line=<value optimized out>)
    at ../sysdeps/posix/system.c:149
#3  0xb678c27d in system (
    line=0x89abf28 "/.../v5-28-00-patches/etc/gdb-backtrace.sh 12339 1>&2") at pt-system.c:29
#4  0xb730867d in TUnixSystem::Exec(char const*) ()
   from /.../v5-28-00-patches/lib/libCore.so.5.28
#5  0xb730f485 in TUnixSystem::StackTrace() ()
   from /.../v5-28-00-patches/lib/libCore.so.5.28
#6  0xb730e80f in TUnixSystem::DispatchSignals(ESignals) ()
   from /.../v5-28-00-patches/lib/libCore.so.5.28
#7  0xb730e91d in SigHandler(ESignals) ()
   from /.../v5-28-00-patches/lib/libCore.so.5.28
#8  0xb7305812 in sighandler(int) ()
   from /.../v5-28-00-patches/lib/libCore.so.5.28
#9  <signal handler called>
#10 __strlen_sse2 () at ../sysdeps/i386/i686/multiarch/strlen.S:99
#11 0xb6ccdc97 in G__valuemonitor(G__value, G__FastAllocString&) ()
   from /.../v5-28-00-patches/lib/libCint.so.5.28
#12 0xb6c60ce0 in G__process_cmd ()
   from /.../v5-28-00-patches/lib/libCint.so.5.28
#13 0xb72ca1bb in TCint::ProcessLine(char const*, TInterpreter::EErrorCode*) ()
   from /.../v5-28-00-patches/lib/libCore.so.5.28
#14 0xb721551c in TApplication::ProcessLine(char const*, bool, int*) ()
   from /.../v5-28-00-patches/lib/libCore.so.5.28
#15 0xb6905948 in TRint::HandleTermInput() ()
   from /.../v5-28-00-patches/lib/libRint.so.5.28
#16 0xb6903fb5 in TTermInputHandler::Notify() ()
   from /.../v5-28-00-patches/lib/libRint.so.5.28
#17 0xb6906e54 in TTermInputHandler::ReadNotify() ()
   from /.../v5-28-00-patches/lib/libRint.so.5.28
#18 0xb730c997 in TUnixSystem::CheckDescriptors() ()
   from /.../v5-28-00-patches/lib/libCore.so.5.28
#19 0xb730cb65 in TUnixSystem::DispatchOneEvent(bool) ()
   from /.../v5-28-00-patches/lib/libCore.so.5.28
#20 0xb727bf61 in TSystem::InnerLoop() ()
   from /.../v5-28-00-patches/lib/libCore.so.5.28
#21 0xb727ecb9 in TSystem::Run() ()
   from /.../v5-28-00-patches/lib/libCore.so.5.28
#22 0xb7213767 in TApplication::Run(bool) ()
   from /.../v5-28-00-patches/lib/libCore.so.5.28
#23 0xb69066e1 in TRint::Run(bool) ()
   from /.../v5-28-00-patches/lib/libRint.so.5.28
#24 0x08048edf in main ()
===========================================================


The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
http://root.cern.ch/bugs. Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#10 __strlen_sse2 () at ../sysdeps/i386/i686/multiarch/strlen.S:99
===========================================================


Root > .q

pcanal · March 30, 2011, 9:29pm

[quote]histos->FindObjectAny(“singles/shDsssdE”)[/quote]should work.
Philippe.

pcanal · March 30, 2011, 9:29pm

Here's the full dump ... if it is of any use for you ...Nope, not this time (it looks like some memory overwrite). I would need you root file.

Cheers,
Philippe.

Pepe_Le_Pew · March 30, 2011, 9:32pm

It works …

root [2] histos->FindObjectAny(“singles/shDsssdE”)
(const class TObject*)0x8f14400
root [3] histos->FindObject(“singles/shDsssdE”)
(const class TObject*)0x8f14400

But I think the “FindFullPathName” should return the leading “/histos” (so that it is easy to use afterwards without any need to modify this string).

Pepe_Le_Pew · March 30, 2011, 9:33pm

Have a look at the first post in this thread … it says where the root file comes from (you can get it from there).
Have fun

pcanal · March 30, 2011, 9:34pm

[quote]But I think the “FindFullPathName” should return the leading “/histos” (so that it is easy to use afterwards without any need to modify this string).[/quote]Both //root/histos and /histos should be working equally well (But only the first one is technically a full pathname).

Cheers,
Philippe.

Pepe_Le_Pew · March 30, 2011, 9:41pm

Yes, that’s exactly how I understand it now.
However, if the “FindFullPathName” unconditionally returns “//root” in the beginning (or “//”), then it will be assumed that you called this method from the “top level” folder, which is not necessarily the case.
If it just returns a leading single “/” then the user is free to add any leading “/top_level_folder” string if needed (and usually it will not be needed).

pcanal · March 30, 2011, 9:43pm

Hi,

Even with the file, I can not reproduce the segmentation fault. What does valgrind report in your case?

Philippe.

Pepe_Le_Pew · March 30, 2011, 9:56pm

I’m not sure if this is what you want … if not, let me know your preferred command …
(and for the moment, my ROOT is not compiled with the “debug” option)

> valgrind /.../v5-28-00-patches/bin/root.exe
==12950== Memcheck, a memory error detector
==12950== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==12950== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==12950== Command: /.../v5-28-00-patches/bin/root.exe
==12950== 
  *******************************************
  *                                         *
  *        W E L C O M E  to  R O O T       *
  *                                         *
  *   Version  5.28/00b     14 March 2011   *
  *                                         *
  *  You are welcome to visit our Web site  *
  *          http://root.cern.ch            *
  *                                         *
  *******************************************

ROOT 5.28/00b (branches/v5-28-00-patches@38394, Mar 30 2011, 16:55:00 on linux)

CINT/ROOT C/C++ Interpreter version 5.18.00, July 2, 2010
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
root [0] TFile *file = new TFile("run.root", "READ");
root [1] TFolder *histos = (TFolder*)(file->FindObjectAny("histos"));
root [2] gROOT->GetRootFolder()->Add(histos)
root [3] gROOT->GetRootFolder()->FindFullPathName("shDsssdE")
==12950== Invalid read of size 1
==12950==    at 0x4026038: strlen (mc_replace_strmem.c:282)
==12950==    by 0x48F3C96: G__valuemonitor(G__value, G__FastAllocString&) (in /.../v5-28-00-patches/lib/libCint.so.5.28)
==12950==    by 0x4886CDF: G__process_cmd (in /.../v5-28-00-patches/lib/libCint.so.5.28)
==12950==    by 0x41E91BA: TCint::ProcessLine(char const*, TInterpreter::EErrorCode*) (in /.../v5-28-00-patches/lib/libCore.so.5.28)
==12950==    by 0x413451B: TApplication::ProcessLine(char const*, bool, int*) (in /.../v5-28-00-patches/lib/libCore.so.5.28)
==12950==    by 0x4F4B947: TRint::HandleTermInput() (in /.../v5-28-00-patches/lib/libRint.so.5.28)
==12950==    by 0x4F49FB4: TTermInputHandler::Notify() (in /.../v5-28-00-patches/lib/libRint.so.5.28)
==12950==    by 0x4F4CE53: TTermInputHandler::ReadNotify() (in /.../v5-28-00-patches/lib/libRint.so.5.28)
==12950==    by 0x422B996: TUnixSystem::CheckDescriptors() (in /.../v5-28-00-patches/lib/libCore.so.5.28)
==12950==    by 0x422BB64: TUnixSystem::DispatchOneEvent(bool) (in /.../v5-28-00-patches/lib/libCore.so.5.28)
==12950==    by 0x419AF60: TSystem::InnerLoop() (in /.../v5-28-00-patches/lib/libCore.so.5.28)
==12950==    by 0x419DCB8: TSystem::Run() (in /.../v5-28-00-patches/lib/libCore.so.5.28)
==12950==  Address 0xd612a380 is not stack'd, malloc'd or (recently) free'd
==12950== 

 *** Break *** segmentation violation
#0  vgModuleLocal_do_syscall_for_client_WRK ()
    at m_syswrap/syscall-x86-linux.S:117
#1  0x38069299 in do_syscall_for_client (tid=1655762656, trc=Cannot access memory at address 0xf
    at m_syswrap/syswrap-main.c:308
#2  vgPlain_client_syscall (tid=1655762656, trc=Cannot access memory at address 0xf
    at m_syswrap/syswrap-main.c:1538
Root > .q
==12950== 
==12950== HEAP SUMMARY:
==12950==     in use at exit: 30,816,550 bytes in 75,705 blocks
==12950==   total heap usage: 702,872 allocs, 627,167 frees, 87,253,575 bytes allocated
==12950== 
==12950== LEAK SUMMARY:
==12950==    definitely lost: 10,377 bytes in 11 blocks
==12950==    indirectly lost: 120 bytes in 10 blocks
==12950==      possibly lost: 290,022 bytes in 6,854 blocks
==12950==    still reachable: 30,516,031 bytes in 68,830 blocks
==12950==         suppressed: 0 bytes in 0 blocks
==12950== Rerun with --leak-check=full to see details of leaked memory
==12950== 
==12950== For counts of detected and suppressed errors, rerun with: -v
==12950== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 51 from 8)

pcanal · March 30, 2011, 9:58pm

[quote]If it just returns a leading single “/” then the user is free to add any leading “/top_level_folder” string if needed (and usually it will not be needed).[/quote]I see. I updated FindFullPathName in revision 38683 so that if you call it from gROOT->GetRootFolder() it does add //root but if you call it from somewhere else it will just add one slash on the name of the folder you call it on.

Cheers,
Philippe.