Home » PANDA » PandaRoot » Bugs, Fixes, Releases » libstt.so error
libstt.so error [message #10409] |
Mon, 15 March 2010 20:01 |
Elisa Fioravanti
Messages: 84 Registered: January 2008
|
continuous participant |
From: *55-79-r.retail.telecomitalia.it
|
|
Hello,
I have installed the new package jan10 in a mac computer (10.5.6)
and pandaroot.
No error with the installation.
When I open root in the gconfig folder loading rootlogon.C, I have the following error:
dlopen error: dlopen(/Users/elisafioravanti/fairsoft/pandaroot/buildPanda/lib/libStt.s o, 9): Symbol not found: __ZN21PndSttTrackFinderReal2PIE
Referenced from: /Users/elisafioravanti/fairsoft/pandaroot/buildPanda/lib/libStt.so
Expected in: flat namespace
Load Error: Failed to load Dynamic link library /Users/elisafioravanti/fairsoft/pandaroot/buildPanda/lib/libStt.so
(int)(-1)
*** Interpreter error recovered ***
Any idea?
Thanks,
Elisa
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: libstt.so error [message #10434 is a reply to message #10428] |
Thu, 18 March 2010 16:46 |
Gianluigi Boca
Messages: 177 Registered: March 2004
|
first-grade participant |
From: *gsi.de
|
|
Johan Messchendorp wrote on Thu, 18 March 2010 15:55 | Hi Gianluigi,
While you trying to fix the problem of Elisa, could you also take a look at the many crashes on various nightly builds machines related to PndSttTrackFinderReal (segfault, time-outs, ...)?
Thanks in advance,
Johan.
|
Like Mr. Obama said,
Yes, we can !
Actually I am in the process of making the Real Patt. Rec. working
on all platform; for instance right now I am working on the problem encountered in running on Mac, I am interacting with Radek for that; also Elisa had a problem - I am not sure on which platform she is working.
I believe the timeouts are related to weird events generated by the MC, but I have not proof for that yet.
Anyways, I will fix that too
Gianluigi
|
|
|
|
|
Re: libstt.so error [message #10437 is a reply to message #10436] |
Thu, 18 March 2010 22:26 |
Johan Messchendorp
Messages: 693 Registered: April 2007 Location: University of Groningen
|
first-grade participant |
From: *xs4all.nl
|
|
Hi,
Well, in principle the dashboard system performs automatically updates and it takes the latest trunk release. Lets wait another day and see what happens. Of course, Ralf has to fix the sds problem first to see the result.... and he did, thkx!
Greetings,
Johan.
[Updated on: Fri, 19 March 2010 14:56] Report message to a moderator
|
|
|
Re: libstt.so error [message #10438 is a reply to message #10437] |
Fri, 19 March 2010 15:14 |
Gianluigi Boca
Messages: 177 Registered: March 2004
|
first-grade participant |
From: *gsi.de
|
|
Johan Messchendorp wrote on Thu, 18 March 2010 22:26 | Hi,
Well, in principle the dashboard system performs automatically updates and it takes the latest trunk release. Lets wait another day and see what happens. Of course, Ralf has to fix the sds problem first to see the result.... and he did, thkx!
Greetings,
Johan.
|
Hi Johan,
so, now the situation looks better as far as the STT real pattern recognition code is concerned.
There is still one situation that I don't understand, in
leonardo.cb.un-bonn.de
1) There, the library libglpk.so is not found. That tells me that on that machine the directory
$VMCWORKDIR/../fairsoft
has not been updated for a long time (end of January).
2) There is still an error in
PndSttTrackFinderReal.h, line 112, "truncated integer ...."
that is clearly obsolete. That tells me that
PndSttTrackFinderReal.h
hasn't been updated for the last few days.
Could you check if it is up-to-date with the svn please?
Gianluigi
|
|
|
Re: libstt.so error [message #10441 is a reply to message #10438] |
Sat, 20 March 2010 14:14 |
Johan Messchendorp
Messages: 693 Registered: April 2007 Location: University of Groningen
|
first-grade participant |
From: *xs4all.nl
|
|
Hi,
The pandaroot releases are updated for the nightly builds. I checked this on a few of them, all seem to be up-to-date. Still, I see problems on 64-bit machines (Debian Lenny and Suse Enterprise), with timeouts (300 secs) for the fourth macro in the stt QA directory...
http://fairroot.gsi.de/CDash/testDetails.php?test=47602&build=17222
http://fairroot.gsi.de/CDash/testDetails.php?test=47632&build=17229
Also on an older 32-bit machine running Fedora, I see a timeout (actually, I manually increased the limit to 600 seconds for this machine)
http://fairroot.gsi.de/CDash/testDetails.php?test=47619&build=17226
The good news... I don't see any crashes anymore. Nevertheless, I wonder about the timeouts, whether the code is not hanging in some infinite loop or whatever. It might be good to build in an internal timeout in the track finding code, not too waste CPU time on hopelessly long taking events. What do you think?
Greetings,
Johan.
|
|
|
|
Re: libstt.so error [message #10443 is a reply to message #10441] |
Sat, 20 March 2010 21:24 |
Gianluigi Boca
Messages: 177 Registered: March 2004
|
first-grade participant |
From: *gsi.de
|
|
Johan Messchendorp wrote on Sat, 20 March 2010 14:14 | Hi,
The pandaroot releases are updated for the nightly builds. I checked this on a few of them, all seem to be up-to-date. Still, I see problems on 64-bit machines (Debian Lenny and Suse Enterprise), with timeouts (300 secs) for the fourth macro in the stt QA directory...
http://fairroot.gsi.de/CDash/testDetails.php?test=47602&build=17222
http://fairroot.gsi.de/CDash/testDetails.php?test=47632&build=17229
Also on an older 32-bit machine running Fedora, I see a timeout (actually, I manually increased the limit to 600 seconds for this machine)
http://fairroot.gsi.de/CDash/testDetails.php?test=47619&build=17226
The good news... I don't see any crashes anymore. Nevertheless, I wonder about the timeouts, whether the code is not hanging in some infinite loop or whatever. It might be good to build in an internal timeout in the track finding code, not too waste CPU time on hopelessly long taking events. What do you think?
Greetings,
Johan.
|
Yes, I will investigate the 'timeouts' problem from now on.
In my experience they are usually caused by very 'messy' events with a lot of hits typically produced by delta rays or so, not originating from the primary vertex.
In this case the real pattern recognition algorithm fails or finds many little tracks and so on. In such cases before finishing, it may try a lot of combinatoric combinations of hits before exhausting all possible combinations, and that may take a lot of CPU time.
Not and infinite loop then, but only a many seconds of CPU comsumption.
Gianluigi
|
|
|
|
Re: libstt.so error [message #10445 is a reply to message #10443] |
Sun, 21 March 2010 18:07 |
Johan Messchendorp
Messages: 693 Registered: April 2007 Location: University of Groningen
|
first-grade participant |
From: *xs4all.nl
|
|
Hi,
Just to let you know, I did some simple investigations running the real track finding QA macro based on the macros in the qa/stt directory. I run on 40 jobs on 40 machines, 10 events (particle gun, each event: 3 mu+ and 3 mu-, 1 GeV/c) each using a different random seed. Only 18 jobs finished within a few minutes successfully, whereas the other 22 are still running (meanwhile more than 350 minutes)... are you sure its not hanging, but still crunching tracks?
Greetings,
Johan.
[Updated on: Sun, 21 March 2010 19:06] Report message to a moderator
|
|
|
|
|
Re: libstt.so error [message #10448 is a reply to message #10444] |
Sun, 21 March 2010 22:29 |
Gianluigi Boca
Messages: 177 Registered: March 2004
|
first-grade participant |
From: *gsi.de
|
|
Johan Messchendorp wrote on Sat, 20 March 2010 21:57 | Hi,
Shall I try to "isolate" a messy event with cause a timeout and give you the root files?
Johan.
|
hi,
tomorrow I will run the DA STT macros and see if they give me the same problem on a SL4.8 Linux machine in Pavia.
Let's see if I can isolate myself the problem and understand if it is a problem of the real p.r. or a problem of in the generation of the events
bis Morgen
Gianluigi
|
|
|
Goto Forum:
Current Time: Mon Dec 09 02:38:45 CET 2024
Total time taken to generate the page: 0.00984 seconds
|