http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=33147
User: gerald
Date: 2010/06/07 12:13 PM
Log:
Copy over r33065 from the trunk:
------------------------------------------------------------------------
r33065 | guy | 2010-06-02 18:22:18 -0700 (Wed, 02 Jun 2010) | 20 lines
Changed paths:
M /trunk/epan/sigcomp-udvm.c
Sorry, I forgot that 8.6. UDVM Cycles says
Note that the number of UDVM cycles MUST NOT be increased if a
request for additional compressed data fails.
so we *shouldn't* increase the cycle count further when
SIGCOMP_INSTR_INPUT_BYTES fails. That does *NOT* of course, mean that
we shouldn't increase the cycle count by 1 for a failed INPUT-BYTES
instruction - that would leave UDVM vulnerable to infinite loops (as per
bug 4826), and I *really* doubt that was their intent; presumably, it
means it should not be increased *by the number of cycles for the
additional data*:
Additionally, if the UDVM successfully requests n bits of
compressed data using one of the INPUT instructions then the
number of available UDVM cycles is increased by n *
cycles_per_bit once the instruction has been executed.
if the attempt to get that additional data fails.
------------------------------------------------------------------------
Copy over with manual intervention:
------------------------------------------------------------------------
r33061 | gerald | 2010-06-02 15:16:49 -0700 (Wed, 02 Jun 2010) | 4 lines
Changed paths:
M /trunk/epan/sigcomp-udvm.c
Increment the cycle count no matter what. Increase the cycle count
further when SIGCOMP_INSTR_INPUT_BYTES fails. Fixes the infinite loop
found in bug 4826.
------------------------------------------------------------------------
Update the release notes.
Directory: /trunk-1.0/docbook/
Changes Path Action
+17 -0 release-notes.xml Modified
Directory: /trunk-1.0/epan/
Changes Path Action
+15 -35 sigcomp-udvm.c Modified