Re: libstc++ (?) problem on CURRENT?

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.


-- 
Good, fast & cheap. Pick any two.