> > Not necessarily relevant but marpa_v_step() can return a negative
> > number on failure, and I think this is not handled. In particular
> > there are a number of cases of unexpected returns from
> > marpa_v_step() which you handle via fall-through which probably are
> > better treated as fatal errors.
>
> > Same with marpa_v_new() -- it can return NULL on failure and this is
> > not checked for. I have no real evidence that this has anything to
> > do with your problem, but this is C language so subtle stuff could
> > be happening with memory overwrites, etc.
>
> Agreed.
>
> > And the checks *do* belong in your final code, so you might as well
> > have them in for debugging.
Assertions and failure handling put in.
No change.
Updated to to libmarpa 8.6.0. (Head of trunk as of sometime today).
No change.
Looked for a way to get more debugging info out of libmrpa, found
_marpa_v_trace().
Activated this.
While my tracing now shows `step-trace` steps as well, it does not
make a change with respect to the other step-types. Still only
step-token and step-inactive.
I believe I will step away from this for a while, do other stuff, let
the back of my mind think about ways of instrumenting marpa_v_next()
to see what it is actually doing in this situation, and other possibilities.
--
See you,
Andreas Kupries <[email protected]>
<http://core.tcl.tk/akupries/>
Developer @ SUSE (MicroFocus Canada LLC)
<[email protected]>
Tcl'2017, Oct 16-20, Houston, TX, USA. http://www.tcl.tk/community/tcl2017/
-------------------------------------------------------------------------------
--
You received this message because you are subscribed to the Google Groups
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
