Army wrote:
- after considering my explanation of the bug, do you have an idea of a
better way to write a test for it? If not, should I just remove the
DERBY-125 test from prepStmt.java?
Not yet; I'll have to think about this some more.
I have just posted a starting point for a test case that I think does what we
want--namely, fails without the patch for DERBY-125 and succeeds with it. It
only throws a protocol exception for JCC, though; it's still a silent failure
for Derby Client. But at least it's a step in the right direction...
- Can you try the experiment of applying all of my patches *except* for
the off-by-one bug (just apply everything, then remove the "+1" from
finalizeDSSLength), and then run
java -Dframework=DerbyNetClient
org.apache.derby.functionTests.harness.RunTest lang/procedure.java
My belief is that you will get an error in the client from the
parseFastVCMorVCS routine in NetStatementReply.java saying that
"only one of the VCM, VCS length can be greater than 0". That, if you
can get it, is proof of the off-by-one bug causing damage.
I was indeed able to reproduce this. Which I guess means that the patch for
DERBY-492 gives us an indirect check for regressions of DERBY-125. If something
happens to regress DERBY-125, we'll start seeing a failure in the DERBY-492
test, and hence we'll (hopefully) catch the regression of DERBY-125. And if
something happens to regress DERBY-492, the test case for DERBY-492 will hang
and thus we should notice that regression, as well.
That said, one further suggestion is that the test case for DERBY-492 be
renamed and/or re-commented to indicate that it actually serves as an indirect
test case for DERBY-125, as well. It's not ideal, but it works. I think it'd
be nice to get another test working independently of DERBY-492 (perhaps based on
the repro I just attached to DERBY-125), but if that came as a separate patch
later on, I personally wouldn't complain.
Army
