Re: Case sensitivity in CLASSIFY and LEARN

On Wed, Oct 1, 2008 at 7:48 PM, James Lee <csejl-/[email protected]> wrote:
> Because that's not an error.  CRM114 read itself in a full buffer
> worth, and that worked just fine.

Yup, one buffer, full. Trouble only starts once that data is stored as
the value of a variable.

Actually, I say this is a bug in crm114 you've run into.

<nitty gritty 'C' code detail mode on>
The different behaviour with/without trap makes sense in a way, as the
error was marked as trappable in the code, yet when caught by a trap
that 'fatalerror5/fatalerror() call will 'return' so the script
execution can continue and actually execute your trap handling script
section -- where the next bit of code will exit crm114 ANYHOW, so no
dice getting that trap section to actually run. And when you did NOT
specify a trap, fatalerror() would already have 'exit()'ed the
building, so you only see anything happening past that call when it IS
trapped. Both ways, you're dead in the water.

What's the bug then? Well, say fatalerror() found the 'trap' in your
script and hence returns to caller so we can go on with our script
(trap section), we STILL don't get a chance as right there in
crm_set_temp_nvar() the code STILL exit()s the building, while it
*should* have simply returned to caller.
<nitty gritty 'C' code detail mode off>


Meanwhile, this error IS 'trappable' (as it does not damage the system
nor our state in unpredictable ways), just as that particular
fatalerror() call would suggest (we have 'untrappableerror()' for
those truely killing failures that are irrecoverable in any way), so
the extra 'ha! you trapped me but, but nah nah, we exit crm114 right
now anyhow' code bit has to go.


Bottom line: unless the crm114 C source code gets fixed, you will
never be able to REALLY trap this baby: when trapped, behaviour will
be very slightly different, but your script won't get a chance anyhow.
(same bug in both vanilla and GerH!)


The relevant diff for the fix in crm_var_hash_table.c:

---------------
   if ( (strlen (varname) + vallen + tdw->nchars + 64) > data_window_size)
     {
-      fatalerror5 ("This program has overflowed the ISOLATEd data "
+        fatalerror("This program has overflowed the ISOLATEd data "
 		  "area with a variable that's just too big.  "
 		  "The bad variable was named: ",
-		   varname, CRM_ENGINE_HERE);
+                varname);
+        return;
-      if (engine_exit_base != 0)
-	{
-	  exit (engine_exit_base + 22);
 	}
-      else
-	exit (EXIT_FAILURE);
-    };

   //       check- is this the first time we've seen this variable?  Or
   //       are we re-assigning a previous variable?
---------------

(BTW: the fatalerror5(xyz, CRM_ENGINE_HERE) is Bill's, fatalerror(xyz)
is mine: same thing, just a diff Bill didn't feel right about back in
'07. C macro stuff to make life easier.)



On Wed, Oct 1, 2008 at 7:48 PM, James Lee <csejl-/[email protected]> wrote:
> Because that's not an error.  CRM114 read itself in a full buffer
>
> worth, and that worked just fine.
>
> - Is it not an error?  If I take out the trap statement it throws an error.  So are you saying that this is a type of error that cannot be trapped because the statement did what it was supposed to do?
>
> {
>    window
>    input (:fifo:) [./bigtext]
> }
>
> crm: *ERROR*
>  This program has overflowed the ISOLATEd data area with a variable that's just too big.  The bad variable was named:  :fifo:
>  Sorry, but this program is very sick and probably should be killed off.
> This happened at line 4 of file trap.crm
> The line was:
> --> input (:fifo:) [./bigtext]
>    <--
>
> This goes back to my daemonization code using FIFO.  Agreed, there are ways to prevent this from happening - don't write to FIFO such a huge amount too fast - but if it happens it'd be nice to trap the error and move on without dying.  A daemon, after all, is supposed to run forever. ;-)
>
> Thanks all for your help.  You guys have been really helpful and I'm learning a lot about CRM114.
>
> -James
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> 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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/