http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1342
------- Comment #17 from luis.ontanon@xxxxxxxxx 2007-04-03 22:31 GMT -------
revision 21332 fixes the over popping of the exception stack on windows by
surrounding the code of
TRY {a} ENDTRY
like
__try { OLDTRY ... } __finalize { OLDENDTRY }
This changes the way it crashes :-\
On windows now tshark -r minimal.pcap reports the stack overflow and finishes,
it works even with -V (>10000 lines of output).
Wireshark on the other hand does the first scan but crashes silently and not
dropping to the debugger when selecting the "evil" packet (21 in the minimal
file). I believe it is due to an out of memory error when showing the tree.
The third or fourth BUG (see discussion bellow) unveiled by the very same
packet, is it a record???
The "evil" packet is certainly malformed the last CHOICE is made of 8 00 bytes
instead of having something meaningful (I guess that's another BUG, not in WS
but in the program that generated it). It triggers the recursion loop that
shows all these issues.
Changing BER_FLAGS_NOOWNTAG for BER_FLAGS_IMPLTAG in the following code stops
the loop and dissects all OK packets OK and reports a malformed packet when it
looks malformed. Is this a bug???
static const ber_choice_t AccessResult_choice[] = {
{ 0, BER_CLASS_CON, 0, BER_FLAGS_IMPLTAG, dissect_failure_impl },
{ 1, BER_CLASS_ANY/*choice*/, -1/*choice*/, BER_FLAGS_NOOWNTAG,
dissect_success1 },
{ 0, 0, 0, 0, NULL }
};
The last (but not least) bug is in dissect_ber_choice that given a sequence of
00's goes into an infinite loop.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.