Re: [Brahms-dev-l] dst2tree crash

From: Truls Martin Larsen <trulsml_at_nbi.dk>
Date: Mon, 02 Apr 2007 08:36:59 +0200
-------- Forwarded Message --------
From: Truls Martin Larsen <trulsml_at_nbi.dk>
To: Flemming Videbaek <videbaek_at_bnl.gov>
Subject: Re: [Brahms-dev-l] dst2tree crash
Date: Fri, 30 Mar 2007 15:09:31 +0200

Hi,

the geometry is used for diagnotics histograms in the selector classes.
Like make distribution of tracks entering the front plane of T1. It is
not necessary for the analysis, I put it in because it made it easier
for me to diagnose problems, like for 200 bad T1 runs in CuCu 62.

The reason it takes so long is the extremely slow response from the file
catalog DB. Asking for the location for about 100 runs (which is needed
before you ask for the geo of a specific run) can take 20-30 min when
you submit a job to condor... also condor might suspend the job for a
while making it take even longer before the eventloop starts.

For every new run in the eventloop the geometry is updated, but I have
never experienced any crash here. Crashes always happens before the
eventloop starts, but that was before the hack was introduced into
dst2tree. I should not happen with the newest version.

I don't have time to do all the changes, to remove all these diagnostics
histograms etc, to get rid of the geo connection, as I have to hand in
my thesis in July. Also I found these diagnostics histograms very useful
when I started doing the CuCu analysis. I also usually take the time to
go through the diagnostics histograms before I proceed with the
analysis. Doing this on 100 dst histogram files, is not an option over
the atlantic, X connections are just too slow.

There is of course no problem in analysing the DSTs directly, and drop
the banapp programs all together, and run proof jobs instead... maybe it
is even faster...

Cheers,
	Truls


On Fri, 2007-03-30 at 08:45 -0400, Flemming Videbaek wrote:
> Hi Truls,
> 
> Maybe it is worthwhile to consider why this at all is nesc. I do not ue the dst2tree at all. What is the DB really used for,
> i.e. what geometry information is it that you need in this this last step? In general it is a bad idea to rely on connection 
> being open for long times
> 
> regards
>     Flemming
> 
> --------------------------------------------
> Flemming Videbaek
> Physics Department 
> Bldg 510-D
> Brookhaven National Laboratory
> Upton, NY11973
> 
> phone: 631-344-4106
> cell:       631-681-1596
> fax:        631-344-1334
> e-mail: videbaek @ bnl gov
> ----- Original Message ----- 
> From: "Truls Martin Larsen" <trulsml_at_nbi.dk>
> To: "Atle Jorstad Qviller" <a.j.qviller_at_fys.uio.no>
> Cc: "Brahms Devel" <brahms-dev-l_at_lists.bnl.gov>
> Sent: Friday, March 30, 2007 8:02 AM
> Subject: [Brahms-dev-l] dst2tree crash
> 
> 
> > Newest version is in CVS. You need to do a checkout of banapp:
> > 
> > do on rcas:
> > klog
> > cvs co banapp
> > 
> > Cheers,
> > Truls
> > 
> > Where do i find this newest version?
> > 
> > atle
> > 
> >> Hi,
> >>
> >> you don't give much information on when it crashes... but I'm guessing
> >> that it happens just before the eventloop starts... The crash you are
> >> seeing is caused be a timeout in the connection to the MYSQL geometry
> >> database. The connection is lost without the DBmanager knowing it. 
> >>
> >> You don't write which version of banapp you are using. There is a hack
> >> in the lastest version the keeps the db connection to be open (by
> >> asking
> >> for a detector volume once in a while) until it is needed for 
> >> initiation
> >> of the Selector classes. Test the lastest version if you are not using
> >> it...
> >>
> >> Cheers,
> >>        Truls
> >>
> >> On Thu, 2007-03-29 at 20:04 +0200, Atle Jorstad Qviller wrote:
> >> I am seeing a lot of crashes when i try to make mdsts for my pp run 5
> > and
> >> 6 analysis. Both MRS and FS settings are affected. This has worked
> > before
> >> for the same settings.
> >> 
> >> Anybody know what causes this? The error message is shown below.
> >> 
> >> cheers
> >> atle
> >> 
> >>
> > ---------------------------------------------------------------------------
> >> 
> >> *** Break *** segmentation violation
> >>  Generating stack trace...
> >> /usr/bin/addr2line: dst2tree: No such file or directory
> >>  0x02f28b6b in BrDetectorVolume::Update() at
> >> /data0/brahmlib/brat/db/geometry/BrDetectorVolume.cxx:574 from
> >> /opt/brahms/new/lib/libBratDb.so.2
> >>  0x02f1da2e in BrGeometryDbManager::BuildDetectorVolume(char const*)
> > at
> >> /data0/brahmlib/brat/db/geometry/BrGeometryDbManager.cxx:337 from
> >> /opt/brahms/new/lib/libBratDb.so.2
> >>  0x02f1d907 in BrGeometryDbManager::GetDetectorVolumeFromMySQL(char
> >> const*, char const*) at
> >> /data0/brahmlib/brat/db/geometry/BrGeometryDbManager.cxx:308 from
> >> /opt/brahms/new/lib/libBratDb.so.2
> >>  0x02f1d0b7 in BrGeometryDbManager::GetDetectorVolume(char const*,
> > char
> >> const*)
> > at /data0/brahmlib/brat/db/geometry/BrGeometryDbManager.cxx:167
> >> from /opt/brahms/new/lib/libBratDb.so.2
> >>  0x0028e368 in TrackSelector::GetDetVolumes() at
> >> /brahms/u/atleq/banapp/selection/TrackSelector.cxx:598 from
> >> /brahms/u/atleq/banapp/lib/banapp/libSelection.so.0
> >>  0x0028abce in TrackSelector::Init(int, int, long long) at
> >> /brahms/u/atleq/banapp/selection/TrackSelector.cxx:101 from
> >> /brahms/u/atleq/banapp/lib/banapp/libSelection.so.0
> >>  0x00d6ba15 in DstLoopModule::Init(char const*, int, int, int) at
> >> /brahms/u/atleq/banapp/anatools/DstLoopModule.cxx:204 from
> >> /brahms/u/atleq/banapp/lib/banapp/libDstLoop.so.0
> >>  0x0804c050 in <unknown> from dst2tree
> >>  0x0804b55d in <unknown> from dst2tree
> >>  0x0101578a in __libc_start_main + 0xda from /lib/tls/libc.so.6
> >>  0x0804a6b9 in std::ios_base::Init::~Init() + 0x31 from dst2tree
> >> Abort (core dumped)
> >> 
> >> 
> >> _______________________________________________
> >> Brahms-dev-l mailing list
> >> Brahms-dev-l_at_lists.bnl.gov
> >> http://lists.bnl.gov/mailman/listinfo/brahms-dev-l
> > -- 
> > *---------------------------------*
> > |http://www.nbi.dk/~trulsml           /
> > |Truls Martin Larsen                       /
> > |trulsml_at_nbi.dk                              .
> > |The Niels Bohr Institute        //
> > |Work Address:                            / \0
> > |Blegdamsvej 17                        /\_/
> > |DK-2100 Copenhagen              /  /
> > |Tel: +45 353 25269            / --
> > |                                              /_/  |
> > |Home address:                  /         \
> > |Holger Danskes Vej 28H|          '
> > |DK-2000 Frederiksberg |
> > |Denmark                             |
> > |Mob: +45 20974802         |
> > *----------------------*
> > 
> > 
> > _______________________________________________
> > Brahms-dev-l mailing list
> > Brahms-dev-l_at_lists.bnl.gov
> > http://lists.bnl.gov/mailman/listinfo/brahms-dev-l
> >

_______________________________________________
Brahms-dev-l mailing list
Brahms-dev-l_at_lists.bnl.gov
http://lists.bnl.gov/mailman/listinfo/brahms-dev-l
Received on Mon Apr 02 2007 - 02:37:46 EDT

This archive was generated by hypermail 2.2.0 : Mon Apr 02 2007 - 02:38:13 EDT