Hello!
As the first author of all this RPC&NFS mess, I just had a short look into all
this. On my (UNIX) machines nothing bad happens at frme 127. It may be really
a Windows compiler problem.
> It seems like I have the following variable contents when the crash occurs:
> string_length_captured = 16384
> string_length = 16384
> string_length_packet = 16384
> string_length_copy = 16384
> exception = 0
> fill_length_packet = 0
> fill_length_captured = 0
Nothing was truncated. Good.
> string_buffer = "2 0 obj <</Type /Page (and so on ....)
> string_buffer_print = "<DATA>"
> string_data = 0
We are called from dissect_rpc_data(), so we don't print the real data.
> tree <> 0
> string_tree <> 0
So no proto_tree_add*() should happen at all (we are in the first run to
contruct the summary line only).
> offset = 132 (128 + 4) since it has been incremented just some line before
> the crash occurs.
That's interesting, as we have in line 620 the first offset+=4. So we are after
this point.
Then comes the string_tree test (line 623, which should do nothing, as we have
string_tree==0)
With this your hint
> Should maybe the lines:
> ---------------------------------
> proto_tree_add_bytes_format(string_tree,
> hfindex, tvb, offset, string_length_copy,
> string_buffer_print,
> "contents: %s", string_buffer_print);
> be changed into something like:
> --------------------------------------------
> proto_tree_add_bytes_format(string_tree,
> hfindex, tvb, offset, string_length_copy,
> string_buffer,
> "contents: %s", string_buffer_print);
becomes irrelevant, as proto_tree_add_bytes_format() should not be called.
But now (line 636) comes the next offset+=string_length_copy, which should
change offset quite a bit. But where exactly are we then? Between the first
offset increase and the second is only 1 comparision between a local variable
and 0. Really mysterious indeed.
Bye, Uwe