DmitryJ added the comment:

Attached please find a patch against the 2.7 branch. CPython built with the 
patch passes the tests from the test suite. Unfortunately, as there is not much 
control over memory allocation, there is no 100% reliable test case that would 
allow for reproducing the reported issue.

Some notes on the patch.

I have studied possible ways of fixing the issue narrowing them to two options; 
the approaches considered were:
a. Patch bytearray methods so they use stringlib's functions with respect to 
the corner case of out-of-bounds access on m = n.
b. Patch fastsearch() avoiding the out-of-bounds access on m = n completely.

Of these two, approach a is less "invasive" as changes, in theory, would be 
contained in bytearray() code only and should not affect any other code. 
Approach b fixes all possible cases, but affects other code not related to 

Upon closer studying of both bytearray and stringlib code, I discovered that it 
might be impossible to patch bytearray code only as stringlib contains a few 
methods that make use of the affected fastsearch() function, see e.g. 
stringlib_partition() as used in bytearray_partition(). If the approach of 
fixing bytearray specific code only would be chosen, I have to incorporate at 
least some of code following the fastsearch() call in stringlib_partition(). 
Similar considerations apply to other bytearray methods that make use of 
stringlib; the amount of code duplication varies. The end result is, I chose to 
patch fastsearch() instead.

Performance wise, the change incurs a small penalty due to one extra branch 
when m != n and brings considerable gain in (potentially rare) case when m = n.

I would appreciate if someone could test and review the patch.

NB. I stand corrected for the comment in msg245457 -- there is a note I missed 
in the C code. My sincere apologies to the author.

keywords: +patch
Added file:

Python tracker <>
Python-bugs-list mailing list

Reply via email to