Re: about lrn freezing Re: [BLAST_SHIFTS] morning shift, 06/01//03

From: Tancredi Botto (tancredi@mitlns.mit.edu)
Date: Sun Jun 01 2003 - 14:13:41 EDT


> I suggest checking if the sourses are sychronized with the binary. Maybe
> did not compile after check out?

they are, but they maybe the "wrong" sources. Anyways, we hope to
have a new tag very soon, with the new FF. Hope you can make it !

> Chi
>
> On Sun, 1 Jun 2003, Tancredi Botto wrote:
>
> >
> > Hi, blast runs out of -rv2 not -rv2.18. As said earlier
> > <dblast07:113> diff ~/lib/libBlast.so ~/cvs_v2/BlastLib2/libBlast.so
> >
> > gives no diff. All changes in v2 are checked in and we (or at least I)
> > always compile out of straight cvs -rv2 check out. Also
> >
> > <dblast07:113> cat ~/cvs_v2/BlastLib2/CVS/Tag gives
> > Tv2
> >
> > Maybe the pid flag is a thing to look at and if so I'll take it out
> > from blastrc. libBlast has not significantly changed in the past 3
> > weeks and I've never experienced such a freeze EXCEPT when you are
> > crunching data and somebody changes/saves lrn.C. Then root may just
> > abort or freeze. Will look into that.
> >
> > This was already discussed and put in the minutes of the last software
> > meeting.
> >
> >
> > As far as havin a deal with satan him/herself, I'll investigate directly.
> >
> >
> >
> > > Hi,
> > >
> > > I think I might know the reason for lrn freesing the console.
> > >
> > > blast is using v2_18 at the moment. There is a bug in particle id routines
> > > that generates seg-fault. it is fixed in v2 top version. Unfortunately,
> > > beam/target polarization info were implememted into TBLRaw v2_18 so they
> > > must be merged before blast can use v2 top version for analysis. I tried
> > > to merge but was not successful. Will try again today or tomorrow so blast
> > > can move on to top version.
> > >
> > > When we pipe unbuffered stream into the null device, we do not see the
> > > message dumped when seg-fault happened which is out put by error stream
> > > which is exactly unbuffered.
> > >
> > > So here is my suggestion, turn off pid when running lrn:
> > >
> > > root -@#$% lrn.C ... -pid ...
> > >
> > > Chi
> > >
> > > P.S. I also spot a strange thing about lrn.C, "scal_inhcharge" is first
> > > used at line 299, but declared at line 469 AND in a else if block. In
> > > principle, it shoudl not run and should complaine about undeclared
> > > variables. As it happens when Tong and I tried to run lrn.C in our own
> > > accounts.
> > >
> > > HOWEVER, IT RUNS IN BLAST ACCOUNT!!!! Maybe Blast had a deal with the
> > > Satan, Aaron?
> > >
> > >
> >
>



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST