Can you try changing packet-rpc.c function dissect_rpc_opaque_data() as
follows :
Change the single line at the beginning of the function from :
string_length_full = rpc_roundup(string_length);
into this instead
string_length_full = MIN(rpc_roundup(string_length),
string_length_captured);
if that does not help, read below
In the trace below:
...
dissect_rpc_opaque_data(tvbuff * 0x02873d74, int 132, _GNode * 0x028c3124,
int 5344, int 0, char * * 0x00000000) line 618 + 38 bytes
dissect_rpc_data(tvbuff * 0x02873d74, _GNode * 0x028c3124, int 5344, int
128) line 675 + 25 bytes
...
Why does offset change from 128 to 132 between the call to
dissect_rpc_data() and dissect_rpc_opaque_data() ?
offset is not changed inside dissect_rpc_data() until after the call to
dissect_rpc_opaque_data() has
completed, and thus dissect_rpc_opaque_data() should have the same value
passed to it.
Is this some weird sideeffect of the debugger on windows? must be.
Something else that is weird. In the call to proto_tree_add_bytes_format()
it seems the length
of the data is 1024 bytes in the trace below.
With desegmenting enabled this data should be something close to 16kb and
not 1kb.
I dont trust that stack trace at all. Is it produced by tools given away
for free by MS?
Do you have a debugger? If so, could you then place a breakpoint in the
beginning of dissect_rpc_opaque_data() and wait until it gets called for
packet 127, then could you write down the result of all assignments of the
local variables until you come down to the call to proto_tree_add_bytes...
----- Original Message -----
From: "Martin Regner"
Sent: Sunday, November 17, 2002 1:15 AM
Subject: Re: [Ethereal-dev] crash on reading tracefile ( NFS ? )
Ronnie Sahlberg wrote:
>Frame 127 is the final segment in a NFS PDU spanning several TCP segments.
>Do you have TCP desegmentation enabled?
>It should be disabled by default but in that case the NFS Read reply should
>show up in frme 112 instead.
>
>If you disable TCP desegmentation, do you still get a crash for packet 127?
No, if TCP desegmentation is turned off then there is no crash. Then you
will only get "RPC continuation" and
no NFS decoding of that packet.
I also tried with tethereal (with TCP desegmentation turned on) and then I
get a crash for packet 127
286 or 610.
The crash seems to occur in g_byte_array_append when dissecting some opaque
data.
MSVCRT! 7800124c()
GLIB-1.3! 00231316()
GLIB-1.3! 00231ef5()
proto_tree_set_bytes(field_info * 0x028d6380, const unsigned char *
0x026d9c98, int 1024) line 909 + 17 bytes
proto_tree_add_bytes(_GNode * 0x0269c700, int 5344, tvbuff * 0x02873d74, int
132, int 1024, const unsigned char * 0x026d9c98) line 862 + 17 bytes
proto_tree_add_bytes_format(_GNode * 0x0269c700, int 5344, tvbuff *
0x02873d74, int 132, int 1024, const unsigned char * 0x026d9c98, const char
* 0x00770f94) line 891 + 29 bytes
dissect_rpc_opaque_data(tvbuff * 0x02873d74, int 132, _GNode * 0x028c3124,
int 5344, int 0, char * * 0x00000000) line 618 + 38 bytes
dissect_rpc_data(tvbuff * 0x02873d74, _GNode * 0x028c3124, int 5344, int
128) line 675 + 25 bytes
dissect_nfsdata(tvbuff * 0x02873d74, int 128, _GNode * 0x028c3124, int 5344)
line 2112 + 21 bytes
dissect_nfs3_read_reply(tvbuff * 0x02873d74, int 128, _packet_info *
0x0106e538, _GNode * 0x028c3124) line 3684 + 24 bytes
Actually someone has reported a similar problem some months ago:
http://www.ethereal.com/lists/ethereal-dev/200203/msg00061.html
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev