[jcifs] SmbComWriteAndX writes corrupt offset to wire

[Michael B Allen]

First, it's time I confess that I failed to mention that Barry (cc'd)
encountered this problem quite a while ago. I didn't tell you yesterday
because I didn't want to pollute your investigation with our ideas. And I
must say you have done a very good job at identifying the issues. Perhaps
Barry can confirm that your observations apply to his situation as well?
You can see in the message linked below that the offset is discussed.
Converting that offset value to hex shows that it indeed has the lower
byte truncated.

http://lists.samba.org/archive/jcifs/2003-October/002586.html

> 2004-04-14 12:53:54,441 ERROR [STDERR] queue.name.eqb:
> writeParameterWordsWireFormat: offset=4000
> 2004-04-14 12:53:54,441 ERROR [STDERR]
> 00000: FF 53 4D 42 2F 00 00 00 00 18 03 80 00 00 00 00  |ÿSMB/...........|
> 00010: 00 00 00 00 00 00 00 00 02 30 0B 70 01 68 5F 0D  |.........0.p.h_.|
> 00020: 0E FF 00 00 00 0E C0>00<0F 00 00 00 00 00 00 00  |.ÿ....À.........|
>
> Note how the offset is corrupt even directly after
> writeParameterWordsWireFormat

Well I'd say that narrows things down quite a bit. Here's the method in
question:

    int writeParameterWordsWireFormat( byte[] dst, int dstIndex ) {
        int start = dstIndex;

        dataOffset = dstIndex + 26; // 26 = off from here to pad

        writeInt2( fid, dst, dstIndex );
        dstIndex += 2;
        writeInt4( offset & 0xFFFFFFFFL, dst, dstIndex );
        dstIndex += 4;
        for( int i = 0; i < 4; i++ ) {
            dst[dstIndex++] = (byte)0x00;
        }
        writeInt2( writeMode, dst, dstIndex );
        dstIndex += 2;
        writeInt2( remaining, dst, dstIndex );
        dstIndex += 2;
        dst[dstIndex++] = (byte)0x00;
        dst[dstIndex++] = (byte)0x00;
        writeInt2( dataLength, dst, dstIndex );
        dstIndex += 2;
        writeInt2( dataOffset, dst, dstIndex );
        dstIndex += 2;
        writeInt4(( offset >> 32 ) & 0xFFFFFFFFL, dst, dstIndex );
        dstIndex += 4;

        return dstIndex - start;
    }

Note the offset variable is a member of SmbComWriteAndX that is set with
setParam in SmbFileOutputStream.write but none of that data is static and
even if a user incorrectly called it concurrently I don't see how it could
account for the bazaar behavior we're seeing. So it has to be something
in this method. What is it about the offset variable that causes *it* to
be encoded incorrectly. Perhaps it's the inlined & 0xFFFFFFFFL or >> ...
etc?

> The interesting thing is that I have found the 'trigger' that causes it
> to 'break'. The previous file copied is longer than normal, and, in
> fact, the offset breaks half way through the file, as follows....
>
> writeParameterWordsWireFormat: offset=100000
> 2004-04-14 12:53:54,244 ERROR [STDERR]
> 00000: FF 53 4D 42 2F 00 00 00 00 18 03 80 00 00 00 00  |ÿSMB/...........|
> 00010: 00 00 00 00 00 00 00 00 02 30 0B 70 01 68 0D 0D  |.........0.p.h..|
> 00020: 0E FF 00 00 00 0D C0>00<86 01 00 00 00 00 00 00  |.ÿ....À.........|
>
> Notice how 92000 is encoded ok, 100000 is encoded incorrectly.
> This longer than normal file seems to be the trigger that permanently
> breaks the encoding.
<snip>
> So back to the test harness - now modified to throw in a few files >
> 100000 bytes. It won't break on Windows at all, and it won't break with
> the client JVM on linux. It only breaks with the -server option. I've
> tried 1.4.2_01 and 1.4.2_04 - same result. I'm downloading 1.5 at the
> moment to see if that changes anything. (And just about to test the real
> application without -server). Will let you know.

Mmm, I modified my test program to write a larger file every 50 loops
with 1.3.1_08-b03 and the -server option compiled on Linux for over
an hour and still I cannot reproduce this :(

[in a followup message ...]

> J2SE 1.5 didn't make any difference, but what did was compiling the
> library myself (using 1.4.2 under windows) - can now run the test
> harness with -server on linux without problem. Also confirmed that the
> real application seems to work ok (so far) without -server.
>
> So looks like I have a couple of choices... don't use -server on linux -
> or - compile the library myself

So -server is required as is compiling on Linux? Did you recompile jCIFS,
your app, or both? I guess this suggests the javac compiler on Linux is
doing something the HotSpot VM doesn't like?

For some reason I cannot get into the java.sun.com bug tracking system
but I sent Java Developer Support a note. Maybe they have some input.

Mike