On Sat, Nov 6, 2010 at 11:44 AM, Barbara <barbara.xxx1975_at_libero.it> wrote: > >>On Sat, Nov 6, 2010 at 11:31 AM, Barbara <barbara.xxx1975_at_libero.it> wrote: >>> >>> >>>>On Sat, Nov 6, 2010 at 10:57 AM, Barbara <barbara.xxx1975_at_libero.it> wrote: >>>>> >>>>> I had a problem running the IcedTea java plugin on CURRENT i386, while it >>>>> works on 8_STABLE. >>>>> But maybe it's not a problem related to the port. >>>>> Just to be clear, I'm not looking for a solution about the port here, I'm >>> just >>>>> wondering why the same c++ code is working on 8_STABLE and it's > segfaulting >>> on >>>>> CURRENT, considering also that AFAIK the gcc version in both the base >>> systems >>>>> is the same. >>>>> >>>>> In the part of the code causing the crash, a std::map is read with an >>> iterator >>>>> in a for loop, and if a condition is met, an entry is erased. >>>>> The following is the bt I'm getting: >>>>> #0 0x29e36247 in kill () from /lib/libc.so.7 >>>>> #1 0x29e361a6 in raise () from /lib/libc.so.7 >>>>> #2 0x282424f6 in XRE_LockProfileDirectory () from >>>>> /usr/local/lib/firefox3/libxul.so >>>>> #3 <signal handler called> >>>>> #4 0x29c8f1b2 in std::_Rb_tree_increment () from >>>>> /usr/lib/libstdc++.so.6 #5 0x2ef92402 in >>>>> IcedTeaPluginUtilities::invalidateInstance () from >>>>> /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so >>>>> ... >>>>> >>>>> I wrote a "patch" for the IcedTea plugin, replacing the for loop with a >>> while >>>>> and increasing the iterator before erasing from the map, and it seems >>> working. >>>>> Then I wrote a simple program that do something similar to IcedTea, so >>> there >>>>> is no need to build the whole java/openjdk6 port to do some testing. >>>>> Running it on 8_STABLE it works, on CURRENT it crashes. >>>>> You can find more details in this discussion on the freebsd-java ml: >>>>> http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html >>>>> >>>>> You can find the patch and the sample code in the discussion above, > anyway >>> I'm >>>>> reporting them here too: >>>>> icedtea patch: >>>>> http://pastebin.com/b2KKFNSG >>>>> test case: >>>>> http://pastebin.com/Amk4UJ0g >>>> >>>>You appear to invalidate the iterator inside the loop and then >>>>increment it. Do the following: >>>> >>>>-- cut here -- >>>>for (iter = cars.begin(); iter != cars.end(); ) { >>>> if ((*iter).second == modelName) >>>> cars.erase(iter++); >>>> else >>>> ++iter; >>>>} >>>>-- and here -- >>>> >>>>In this example, you first increment the iterator and then erase its >>>>previous value. >>>> >>> >>> So there is a bug in my source code! Well, I'm not surprised. >>> >>> I'm trying to report the code in icedtea here, extracting it from the patch > so >>> I hope it's accurate enough: >>> >>> std::map<void*,NPP>::iterator iterator; >>> for (iterator = instance_map->begin(); iterator != instance_map->end(); >>> iterator++) >>> { >>> if ((*iterator).second == instance) >>> { >>> instance_map->erase((*iterator).first); >>> } >>> } >>> >>> So, do you think, like Ed Schouten said, that there is a bug in the source >>> code but it's just exposed on CURRENT? >>> Is that code bad too? >>> >>> Thanks >>> Barbara >>> >>> >> >>Yes, I believe CURRENT's malloc zeroes out the memory upon deletion, >>whereas STABLE doesn't. So in STABLE you get an old copy of the >>invalidated iterator, hence it works. >> > > Very nice explanation. > > Thanks > > I hope I'm right, I don't have CURRENT installed, it's just an assumption. However, the C++ code is most definitely buggy. -- Good, fast & cheap. Pick any two.Received on Sat Nov 06 2010 - 09:48:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:08 UTC