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

From: Vlad Galu <dudu_at_dudu.ro>
Date: Sat, 6 Nov 2010 11:47:16 +0100
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