Re: problem with trainin since upgrade to blamethesegfault

Um, thanks. But we're missing something here. I would almost start to believe...

I got your log, checked the whole bunch and the spot where it CAN go
bad is right there in mailtrainer (why it is there and only in a few
spots, Bill probably knows, but that's not really relevant right now.
Please bear with me...)

Here's the clipout from the mailtrainer log:

---------------------------------------
Parsing line 501 :
 -->  input [:*:gooddir::*:filename: 0 :*:decision_length:]
		

Executing line 501 :
executing an INPUT statement
  from filename
>>>reaver_cache/known_good/reaver_cache/known_good/20080403_110137_105711_5D6BA7AD<<<
  pre-IO seek to >>>0<<< --> 0
  and maximum length IO of >>>16000<<< --> 16000
Opening file reaver_cache/known_good/reaver_cache/known_good/20080403_110137_105711_5D6BA7AD
for file I/O (reading)
ifn='reaver_cache/known_good/reaver_cache/known_good/20080403_110137_105711_5D6BA7AD',
filename=':*:gooddir::*:filename: 0 :*:decision_length:', errno=2,
error='No such file or directory'
Catching FAULT generated on line 501
FAULT reason:

crm: *ERROR*
 For some reason, I was unable to read-open the file named
:*:gooddir::*:filename: 0 :*:decision_length:
 Sorry, but this program is very sick and probably should be killed off.
This happened at line 501 of file mailtrainer.crm
(runtime system location: crm_expr_file_io.c(154) function crm_expr_input)

Trying trap at line 502:
trap /unable to read-open/
		
This TRAP will trap anything matching =unable to read-open= .
TRAP matched.
Next statement will be 502

Parsing line 503 :
 -->  input [:*:filename: 0 :*:decision_length:]
		

Executing line 503 :
executing an INPUT statement

---------------------------------------


So you MIGHT think "Ha! Got It!" but NOPE, this is 'good' in the sense
that that

  Trying trap at line 502:
  trap /unable to read-open/

is in there, intentionally, and DOES catch the error, after which it
tries this one successfully:

  Parsing line 503 :
   -->  input [:*:filename: 0 :*:decision_length:]

And at the end of the run, the mailtrainer report comes out, no errors
what-so-ever (like it should!) mentioned there and when I track the
remainder of the mailreaver log too, I find that this looks like a
PROPER run.

In other words: the FAILURE you mentioned doesn't seem to happen here
& now for reasons unknown. :-S :-S


Dang!

Can you just run that mailreaver bugger like you did before, so
without the '-t' tracing, and check for me if that 'cannot open' error
we started with, pops up again?
Just to make it's still there when run like usual.

Because if it is, then we need to see what is different between the
'-t' runs and that one and if we can get logs with the error in there
somehow.
And if it isn't, we've some more headscratching to do, because then
it's opportune to find when the error occurs and keep that situation
reproducible somehow.



So can you check for me if the mailreaver still coughs up a hairball
when run without the '-t' stuff like old? Thanks!

Ger









On Thu, Apr 3, 2008 at 4:20 AM, Jason Lewis <[email protected]> wrote:
> Ger Hobbelt wrote:
>
>
> >
> > Jason, can you send me another log.7z after this mailtrainer.crm test
> > run? Thanks!
> >
> >
>
>  Log is here:
>
>  http://flip.dyndns.org/downloads/log.7z
>
>  Jason
>
>



-- 
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
--------------------------------------------------

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace