Re: problem with trainin since upgrade to blamethesegfault

Oh, before I forget: I got on the line with Jason after this, had a
look and the problem has been fixed now; turned out it was due to
'configuration': as he was testing the new release/builds, the new
crm114 binary was run using a path to the new crm114, which is
perfectly fine, which would run mailreaver.crm. However,
mailreaver.crm will start a shell (syscall) to run mailtrainer.crm
using another IMPLICIT instance of CRM114, as identified in the 'bang
line' of the executable mailtrainer.crm script. THIS instance would be
'located' by the shell invoked through syscall and, as it turned out,
was NOT the latest build but an older one.

It was resolved by modifying the proper mailfilter.cf (i.e the one in
the same directory as where the mailreaver and mailtrainer used were
located) to invoke mailreaver not as simply './mailreaver.crm' but
with a hardcoded FULL PATH to crm114 like this: '/tmp/...../crm114
mailreaver.crm' and the problem was gone.

FYI and in case somebody else runs into similar hard-to-track-down
problems in the future.

I'd say it can be formulated for a FAQ or other documentation thus:

-----
When you invoke mailreaver/mailtrainer/... crm scripts by specifying
your selected crm114 binary on the commandline, so running the scripts
in any other way than by just invoking them like './mailreaver.crm
<commandline arguments>', make sure that you adapt your mailfilter.cf
file accordingly to invoke the mailtrainer.crm script listed in there
there same way.
-----

That should cover it a la UNIX man page. ;-) (= "once you've found out
the _hard_ way, the man page is suddenly, glaringly, obvious")


Cheers,

Ger


On Thu, Apr 3, 2008 at 5:47 PM, Paolo <[email protected]> wrote:
> On Thu, Apr 03, 2008 at 04:30:59PM +1100, Jason Lewis wrote:
>  ...
>
> > > fprintf-->snprintf and placing thus generated message inside the
>  > > fatalerror() call, instead of pushing it out to stderr immediately.
>  >
>  > Which error should be gone for good?
>  >
>  > I still get the training error:
>  >
>  > /tmp/crm114-20070810-BlameTheSegfault.src/crm114 -u
>  > /home/jason/.crm114working/ /home/jason/.crm114working/mailreaver.crm
>  > --good  <
>  > /home/jason/Maildir/.ygood/cur/1207200462.M173503P6439V000000000000FD02I000000002C041267_0.debian,S=1353:2,S
>  >   >  /home/jason/.crm114working/164561207200481989640077
>  > ifn='reaver_cache/known_good/reaver_cache/known_good/20080403_162729_032893_FFFFFFFFEDDBA61B',
>  > filename=':*:gooddir::*:filename: 0 :*:decision_length:', errno=2,
>  > error='No such file or directory'
>
>  either you didn't patch the .c, didn't recompile or are still running the old
>  binary. Modified src would have printed
>  'For some reason, I was unable to read-open ...'
>  along with 'ifn=...'.
>
>  Anyway, I think Gerrit is right, there's no bug, the bugger is ... your
>  patch :) - without the on purpose lines in mail*.crm we added on other
>  occasion, we're missing the context from the log and are faked to to believe
>  there's a bug.
>
>  Hum, all this happened around April 1, maybe there's a pttern ;)
>
>  But that's been useful to expose a bug (imo), here's the problem/dangerous
>  code:
>
>  #--[mailtrainer.crm]---
>  ...
>  @462        {        #   Maybe it's a qualified name, maybe it's not
>
>                 input [:*:filename: 0 :*:decision_length:]
>
>                 trap /unable to read-open/
>
>                 output /\n COULDN'T READ THE GOOD FILE ':*:filename:' \n/
>                 alter (:_dw:) /:*:_nl:/
>             }
>  ...
>  alius
>  ...
>  @499        {        #   Maybe it's a qualified name, maybe it's not
>                 input [:*:gooddir::*:filename: 0 :*:decision_length:]
>
>                 trap /unable to read-open/
>
>                 input [:*:filename: 0 :*:decision_length:]
>
>                 trap /unable to read-open/
>
>                 output /\n COULDN'T READ THE GOOD FILE ':*:filename:'\n/
>                 alter (:_dw:) /:*:_nl:/
>             }
>  ...
>  #--------------------------
>
>  our trouble line is @500, but I think that's the good one, missing from
>  block above ALIUS, while the next INPUT try should be removed.
>  Both mailreaver and mailtrainer read the .cf where :gooddir: is defined,
>  but :filename: passed by mailreaver includes :gooddir: as well.
>
>  Insted mailreaver should use just the bare filename, and mailtrainer
>  shouldn't try-open here and there: it's supposed to work in a well defined
>  dir and read good/spam from well defined dirs, if it fails there's an error
>  or the file disappeared.
>
>  Keeping the lines with :*dir: in makes sense since mailtrainer may run
>  standalone.
>
>  Going to check mail{trainer,reaver}.crm, will post tonight hacked versions
>  if time permits.
>
>
>  --
>   paolo
>
>   GPG/PGP id:0x3A47DE45  - B5F9 AAA0 44BD 2B63 81E0  971F C6C0 0B87 3A47 DE45
>   - 9/11: the outrageous deception and ongoing coverup: http://911review.org -
>
>
>
>  -------------------------------------------------------------------------
>  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
>  _______________________________________________
>  Crm114-general mailing list
>  [email protected]
>  https://lists.sourceforge.net/lists/listinfo/crm114-general
>
>



-- 
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 
Register now and save $200. Hurry, offer ends at 11:59 p.m., 
Monday, April 7! Use priority code J8TLD2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone