GSI Forum: Bugs, Fixes, Releases » libstt.so error

Home » PANDA » PandaRoot » Bugs, Fixes, Releases » libstt.so error

Show: Today's Messages :: Polls :: Message Navigator

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

Report message to a moderator

Re: libstt.so error [message #10412 is a reply to message #10409]

Tue, 16 March 2010 18:21

Gianluigi Boca
Messages: 177
Registered: March 2004

first-grade participant

From: *gsi.de

I think you should update the fairsoft part of the code because the location of the glpk .so library has changed since some time ago
Gianluigi

Report message to a moderator

Re: libstt.so error [message #10413 is a reply to message #10412]

Tue, 16 March 2010 18:23

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: *to.infn.it

Hi Gianluigi,
from a discussion with Elisa yesterday, as far as I have understood this was already done (as explained in a Mohammad message in the forum). Indeed the error is not in glpk but in this PI function/member of TrackFinderReal.

Report message to a moderator

Re: libstt.so error [message #10414 is a reply to message #10413]

Tue, 16 March 2010 21:43

Gianluigi Boca
Messages: 177
Registered: March 2004

first-grade participant

From: *gsi.de

Stefano Spataro wrote on Tue, 16 March 2010 18:23

Hi Gianluigi,
from a discussion with Elisa yesterday, as far as I have understood this was already done (as explained in a Mohammad message in the forum). Indeed the error is not in glpk but in this PI function/member of TrackFinderReal.

Hi Stefano,
ok, I agree it is not glpk. The fact is that PI is a
static const Double_t equal to 3.14.....etc.etc

defined in PndSttTrackFinderReal.h

I don't see how suddenly it doesn't work anymore : the code itself has worked at least until the last collaboration meeting - thanks God!

It is a fact though that today Radek and tonite myself are experiencing also a new very strange behaviour of the PndSttTrackFinderReal : the macro macro/stt/runreco.C
(with PndSttTrackFinderReal(iVerbose) in place of the
PndSttTrackFinderIdeal(iVerbose) )

stops without any crash at the first event, at the point
where the function PndTrkFinderPartial( ) is called.
At the moment I don't have the slightest idea why - it looks like
some memory leak somewhere else.

So could Elisa's problem be related to this ?

Has anybody made changes in some part of the code causing this??

Gianluigi

Report message to a moderator

Re: libstt.so error [message #10415 is a reply to message #10409]

Wed, 17 March 2010 09:30

Elisa Fioravanti
Messages: 84
Registered: January 2008

continuous participant

From: *fe.infn.it

Hello,

I can confirm that I have already updated the fairsoft part (following the instruction for the glpk post in the forum).
The problem seems to be in the PndSttTrackFinderReal.

Thanks,
Elisa

Report message to a moderator

Re: libstt.so error [message #10423 is a reply to message #10415]

Wed, 17 March 2010 16:06

Gianluigi Boca
Messages: 177
Registered: March 2004

first-grade participant

From: *gsi.de

Elisa Fioravanti wrote on Wed, 17 March 2010 09:30

Hello,

I can confirm that I have already updated the fairsoft part (following the instruction for the glpk post in the forum).
The problem seems to be in the PndSttTrackFinderReal.

Thanks,
Elisa

Now the problem seems to be fixed, at least for the Scientific Linux version 4.8 machine (Radek reports it is still not working on his Mac).

Please update repository the stt directory and test

Gianluigi

Report message to a moderator

Re: libstt.so error [message #10425 is a reply to message #10409]

Wed, 17 March 2010 17:26

Elisa Fioravanti
Messages: 84
Registered: January 2008

continuous participant

From: *53-79-r.retail.telecomitalia.it

Hello Gianluigi,

as Radek, I have again the same problem as before.

Elisa

Report message to a moderator

Re: libstt.so error [message #10428 is a reply to message #10409]

Thu, 18 March 2010 15:55

Johan Messchendorp
Messages: 693
Registered: April 2007
Location: University of Groningen

first-grade participant

From: *xs4all.nl

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.

Report message to a moderator

Re: libstt.so error [message #10430 is a reply to message #10428]

Thu, 18 March 2010 16:06

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: *to.infn.it

Hi,
as far as I have understood the crashes are coming from sds (?) code, not from stt.

Report message to a moderator

Re: libstt.so error [message #10431 is a reply to message #10430]

Thu, 18 March 2010 16:12

Johan Messchendorp
Messages: 693
Registered: April 2007
Location: University of Groningen

first-grade participant

From: *xs4all.nl

Hi,

I am talking about the crashes related to the QAmacro_stt_4.sh QA macro, which has problems and is identical to QAmacro_stt_2.sh, however with the real track finding switched on in stead of the ideal one.... there is no sds in there, or am I wrong?!?

Johan.

Report message to a moderator

Re: libstt.so error [message #10432 is a reply to message #10431]

Thu, 18 March 2010 16:15

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: *to.infn.it

In my dashboard ALL the qa macros are crashing because Sds

dlopen error: /home/spataro/jan10/cbuild/lib/libSds.so: undefined symbol: _ZN22PndSdsStripHitProducer16SetParContainersEv
Load Error: Failed to load Dynamic link library /home/spataro/jan10/cbuild/lib/libSds.so

Report message to a moderator

Re: libstt.so error [message #10433 is a reply to message #10432]

Thu, 18 March 2010 16:20

Johan Messchendorp
Messages: 693
Registered: April 2007
Location: University of Groningen

first-grade participant

From: *xs4all.nl

that is a new one .... Ralf... heeellllp Sad

Sad

j.

[Updated on: Thu, 18 March 2010 16:44]

Report message to a moderator

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

Report message to a moderator

Re: libstt.so error [message #10435 is a reply to message #10409]

Thu, 18 March 2010 20:57

Elisa Fioravanti
Messages: 84
Registered: January 2008

continuous participant

From: *19-79-r.retail.telecomitalia.it

Hi Gianluigi,

I'm also working on a MAC computer (10.5.6)

Thanks,

Elisa

Report message to a moderator

Re: libstt.so error [message #10436 is a reply to message #10428]

Thu, 18 March 2010 22:21

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.

Hi,
I took a look to the dashboard messages for PndSttTrackFinderReal.

I think all those errors I have already fixed in the last few days.
Please update PndSttTrackFinderReal.cxx and .h
and they should disappear hopefully

Tschuess Gianluigi

Report message to a moderator

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

Report message to a moderator

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.

Report message to a moderator

Re: libstt.so error [message #10442 is a reply to message #10441]

Sat, 20 March 2010 14:18

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: *4-87-r.retail.telecomitalia.it

Hi,
as far as I have seen running the qa macros outside dashboars, the simulation is stucked at a well defined EvtGen event (sim_complete_XXX), where it stays for several seconds. Maybe one should fix at that event, and to check if it is a problem of montecarlo (i.e. a huge shower creating thousands of points?) or related to our code.

Report message to a moderator

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

Report message to a moderator

Re: libstt.so error [message #10444 is a reply to message #10443]

Sat, 20 March 2010 21:57

Johan Messchendorp
Messages: 693
Registered: April 2007
Location: University of Groningen

first-grade participant

From: *xs4all.nl

Hi,

Shall I try to "isolate" a messy event with cause a timeout and give you the root files?

Johan.

Report message to a moderator

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 #10446 is a reply to message #10445]

Sun, 21 March 2010 21:00

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: *5-87-r.retail.telecomitalia.it

I think we are speaking about two different things. I have seen that for some particular evtgen the simulation stays for a long time, regardless of tpc/stt. I have not checked the reco part, even because when the sim fails (timeout) also the other macros are failing.

Report message to a moderator

Re: libstt.so error [message #10447 is a reply to message #10446]

Sun, 21 March 2010 22:05

Johan Messchendorp
Messages: 693
Registered: April 2007
Location: University of Groningen

first-grade participant

From: *xs4all.nl

we indeed are talking about two different things.... the problem I encounter is done with the particle gun and really points to the real track finding algorithm of the STT. The ideal track finding works ok on the same events.

Johan

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

Report message to a moderator

Previous Topic:	Memory leak fixed
Next Topic:	'timeouts' problem fixed

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

PDF

]

Current Time: Sun Dec 01 12:04:35 CET 2024

Total time taken to generate the page: 0.00829 seconds