Re: still getting errors with CRM

On Thu, Apr 24, 2008 at 2:21 PM, Bill Y <[email protected]> wrote:
>  That's the problem then!
>
>  Check to see that the file priolist.mfp exists in the
>  directory you're "-u"-ing into, and that it's at least -rx world.
>
>           - Bill Yerazunis

One correction: -r- world is enough; 'x' is not necessary.



NB: I'll put my chips on 'the mfp file is there all right', because
that's what I remember was the case also when we previously looked at
this issue reported by Jason - please refer also to the thread started
by Jason's message at 18/03/2008 22:09 - this stuff has a history.

And to ensure we're not doing that part of the exercise again but can
quickly continue where that was left off, here's the list to tick off:

- priolist.mfp exists in the -u path and has sufficient access rights.
(Besides, remember the error is intermittent at a ~ 5 promille rate,
so the file is 'there' the other 99.5% of the time)
- priolist.mfp and none of the other files reside on any network
share: they all exist on local storage
- OS is 64-bit Debian

so everyone is on the same page.


Next thing to do before we put on the surgical gloves: crm114 -t (-T
is way too abusive to use that in the same round).

==>

Jason, can you create another run, but now with the extra commandline
argument '-t' (note the case) for crm114, like 'crm114 -t -u ... etc
...' ?

Be aware that this will create a VERY large amount of output on
stderr, so you may wish to redirect that to file. (You don't want to
watch that stderr stream 'live', I can assure you.)
The easiest way to fetch the maybe-relevant blurb(s) from there is
then running 'grep' on the logfile on this program, like so:

  grep -B300 -A30 "For some reason"
the_stderr_logfile_of_the_1000_run.log > relevant_bits.log

What this does is find those *ERROR* messages in there and copy the
blurb from 300 lines 'B'efore the error to '30' 'A'fter/beyond to
stdout, redirected to relevant_bits.log
The few lines 'A'fter are useful so we get to see the complete error
message (again) and a bit of stuff that follows, while the 300
'B'efore MAY give us a bit of a hint what's going down there, while
leading up to the failure.

A complete lack of content in 'relevant_bits.log' is another thing
that MAY happen as we're having a timing-based issue here and changing
crm114 time-related behaviour due to enabling user-level logging may
very well make the bug hide for cover. This is not what I hope will
happen, but there's a reasonable probability it can happen. Better
beware and expect surprises.


step 2)

When this 'crm114 -t' still makes the error appear, I suggest adding
the '-T' argument to the crm commandline as well and let that run too;
same grep line to follow to check if the error happened again.

What this tells us, besides producing a sh**load of logging, is how
'stable' the appearance of this bug is. It may shift to other spots,
i.e. the error message may change, or may disappear entirely. What I
need to know is if the error stays around at all with '-t' and '-t
-T', because that helps delimit our expectations properly for what is
to come.




Thanks and I'll be listening on the ML for the run/log results.


-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web: http://www.hobbelt.com/
 http://www.hebbut.net/
mail: [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone