XStream
  1. XStream
  2. XSTR-584

Infinite loop due to unsafe collection usage

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.1
    • Fix Version/s: 1.4
    • Component/s: None
    • Labels:
      None
    • JDK version and platform:
      Sun 1.6.0_14 64bit for Linux

      Description

      com.thoughtworks.xstream.io.xml.XmlFriendlyReplacer makes use of 2 WeakHashmaps to hold string.
      Those maps are accessed multi-threaded, but are not synchronized.

      This can lead to access on those maps occupying all CPU-resources, which can only get solved by restarting the VM.
      This happens under rare heavily multi-threaded circumstances, nevertheless the impact is critical. Testsystem: 8 * Intel(R) Xeon(R) CPU E5345 @ 2.33GHz, 32GB RAM, FS on SAN
      See attached stacktrace, with lots of threads bein in
      at java.util.WeakHashMap.get(WeakHashMap.java:355)
      at com.thoughtworks.xstream.io.xml.XmlFriendlyReplacer.escapeName(XmlFriendlyReplacer.java:67)
      and occupying the CPU.

      Also see Scott.Stark's comment in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=85301 for the same problem.

      Suggested solution: Use synchronized WeakHashmap, see attached patch. (To check: performance impact? If yes, a non-synchronized, but thread-safe implementation would be suitable like ConcurrentSkipListMap).

      1. stack_xstream.txt
        270 kB
        Rico Neubauer
      2. xstream_unsafe_collection.diff
        1 kB
        Rico Neubauer

        Activity

        Hide
        Jörg Schaible added a comment -

        Hi Rico,

        thanks for reporting, I've synchronized it now. If it causes a race condition it must be fixed. We will change in the complete naming mechanism something anyway, so it is fine with the synch. For a workaround with the reeleased version, simply derive from the XmlFriendlyReplacer and overwrite the complete implementation with yours. While you will have the member fields doubled, it does not really matter for the functionality

        Cheers,
        Jörg

        Show
        Jörg Schaible added a comment - Hi Rico, thanks for reporting, I've synchronized it now. If it causes a race condition it must be fixed. We will change in the complete naming mechanism something anyway, so it is fine with the synch. For a workaround with the reeleased version, simply derive from the XmlFriendlyReplacer and overwrite the complete implementation with yours. While you will have the member fields doubled, it does not really matter for the functionality Cheers, Jörg
        Hide
        Thomas Sartissohn added a comment -

        Hi,

        any idea when this fix will be available in a new release?
        Is there any plan when the new version is released?

        Thomas

        Show
        Thomas Sartissohn added a comment - Hi, any idea when this fix will be available in a new release? Is there any plan when the new version is released? Thomas

          People

          • Assignee:
            Jörg Schaible
            Reporter:
            Rico Neubauer
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: