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 [EMAIL PROTECTED] http://www.ethereal.com/mailman/listinfo/ethereal-dev
