Then it is strange, when Jason experienced a freezing, I tried to run
v2_top (although from my account) on that run and I passed through the
freezing event. At the moment of freezing, seemed no body was
changing it but we only asked arrond the counting bay.
v2_18 do crash on that exact event though, that is the what led me to
suspect pid routines. I wrote that part, but never had the chance to
really shake the codes down. I am doing that now, hopefully in a few days,
pid part of the codes will become more robust.
I suggest checking if the sourses are sychronized with the binary. Maybe
did not compile after check out?
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