Issue1098

PyStringMap has a nasty bug where if it has a size exactly equal to one
of the numbers in PyStringMap.primes and is serialized and deserialized,
all get caught in an infinite loop.

A test case is attached.  Results and a stck dump are below.  Note that
the main thread is stuck in a busy wait in PyStringMap.__finditem__:

---
trying size 0
0
None
trying size 1
1
None
trying size 2
2
None
trying size 3
3
None
trying size 4
4
None
trying size 5
5
None
trying size 6
6
None
trying size 7
7
None
trying size 8
8
None
trying size 9
9
None
trying size 10
10
None
trying size 11
11
None
trying size 12
12
None
trying size 13
13
^\Full thread dump Java HotSpot(TM) Client VM (1.5.0_13-119 mixed mode,
sharing):

"Low Memory Detector" daemon prio=5 tid=0x01008fe0 nid=0x81d000 runnable
[0x00000000..0x00000000]

"CompilerThread0" daemon prio=9 tid=0x01008510 nid=0x81c200 waiting on
condition [0x00000000..0xb0b077d8]

"Signal Dispatcher" daemon prio=9 tid=0x010080a0 nid=0x81b400 waiting on
condition [0x00000000..0x00000000]

"Finalizer" daemon prio=8 tid=0x010078e0 nid=0x817c00 in Object.wait()
[0xb0a05000..0xb0a05d90]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x25a7ee30> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
        - locked <0x25a7ee30> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=10 tid=0x01007500 nid=0x816400 in
Object.wait() [0xb0984000..0xb0984d90]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x25a7eeb0> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:474)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
        - locked <0x25a7eeb0> (a java.lang.ref.Reference$Lock)

"main" prio=5 tid=0x010013b0 nid=0xb0801000 runnable
[0xb07ff000..0xb0800188]
        at org.python.core.PyStringMap.__finditem__(Unknown Source)
        - waiting to lock <0x25610028> (a org.python.core.PyStringMap)
        at org.python.core.PyStringMap.__finditem__(Unknown Source)
        at org.python.core.PyStringMap.get(Unknown Source)
        at org.python.core.PyStringMap.get(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.python.core.PyReflectedFunction.__call__(Unknown Source)
        at org.python.core.PyMethod.__call__(Unknown Source)
        at org.python.core.PyObject.__call__(Unknown Source)
        at org.python.core.PyObject.invoke(Unknown Source)
        at
org.python.pycode._pyx0.f$0(../../colin/jython/stringmaptest.py:20)
        at
org.python.pycode._pyx0.call_function(../../colin/jython/stringmaptest.py)
        at org.python.core.PyTableCode.call(Unknown Source)
        at org.python.core.PyCode.call(Unknown Source)
        at org.python.core.Py.runCode(Unknown Source)
        at org.python.core.__builtin__.execfile_flags(Unknown Source)
        at org.python.util.PythonInterpreter.execfile(Unknown Source)
        at org.python.util.jython.main(Unknown Source)

"VM Thread" prio=9 tid=0x01006c50 nid=0x815600 runnable 

"VM Periodic Task Thread" prio=9 tid=0x0100a790 nid=0x805800 waiting on
condition 

"Exception Catcher Thread" prio=10 tid=0x01001600 nid=0x809800 runnable

The bug is caused because PyStringMap.readObject() doesn't ensure that
there is a null entry, which causes PyStringMap.__finditem__() to loop
when trying to retrieve keys that are not in the map.  The easy fix is
to add 1 to the required capacity in PyStringMap.readObject().

This bug doesn't exist in 2.5 because it uses a ConcurrentHashMap as the 
underlying storage mechanism, instead of key/value arrays.

(Certainly worth fixing in 2.2.2, of course.)

If the bug is fixed in 2.5, do we need to keep this bug report open?

Do we have any plans to release a maintenance release of 2.2?

2.2 is in security-fix-only mode at best. I haven't tried to build it in so long I'm not even sure how easy it would be to apply fixes. This one is definitely below that threshold so closing.