Sorry for the lack of timeliness on responding to this. Our mailserver has been
about to be back up any minute now for a couple of days.
The test case that I ran was even more brutal than what your test module does.
Basically I have a small piece of code that puts each byte in its own bucket and
each bucket in its own brigade.
Brian's patch will not handle this case because there is no next bucket to point
tag_start_index at. I was a little vague in my description of the problem. Basically,
if the <!--# tag occurs at the end of one brigade and the directive starts at the
beginning of the next brigade we have trouble. In my tests this was causing a
core dump which my patch fixed.
I'm also surprised that the include virtual was failing since it passed my tests. :(
I'll double check those results to see if I missed something.
Also, Brian, I do not see where the comment you removed was invalid. Slen is only
ever set to ctx->start_seq_len (which by default is 5 I believe). Slen is never changed
to be any number other than ctx->start_seq_len.
I do not claim to have studied bndm enough to be certain, but it seems to me that
if the brigade has a single bucket with a single byte which hapens to match within
the pattern then you will end up incrementing ctx->bytes_parsed by pos+slen (where
slen == 5) when only one byte was processed.
That is to say, len == 1, so it will enter the "if (len)" conditional block around line 472.
Bndm can match the pattern and return pos = 0, so it enters the (pos != len) conditional
block. At the end of this block it increments ctx->bytes_parsed by pos+slen even
though it only processed one byte. The previous bytes will have already been
accounted for during runs through find_start_sequence for previous brigades.
Where am I confused?
Sorry again for the delay in responding.
Paul J. Reder
