Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 6 Nov 2010 11:44:00 +0100 (CET)
From:      Barbara <barbara.xxx1975@libero.it>
To:        <freebsd-current@freebsd.org>
Cc:        dudu@dudu.ro
Subject:   R: Re: libstc++ (?) problem on CURRENT?
Message-ID:  <21554061.928151289040240274.JavaMail.defaultUser@defaultHost>

next in thread | raw e-mail | index | archive | help

>On Sat, Nov 6, 2010 at 11:31 AM, Barbara <barbara.xxx1975@libero.it> wrote=
:
>>
>>
>>>On Sat, Nov 6, 2010 at 10:57 AM, Barbara <barbara.xxx1975@libero.it> wro=
te:
>>>>
>>>> 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=20
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 =C2=A00x29e36247 in kill () from /lib/libc.so.7
>>>> #1 =C2=A00x29e361a6 in raise () from /lib/libc.so.7
>>>> #2 =C2=A00x282424f6 in XRE_LockProfileDirectory () from
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/local/lib/firefox3/libxul.so
>>>> #3 =C2=A0<signal handler called>
>>>> #4 =C2=A00x29c8f1b2 in std::_Rb_tree_increment () from
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/lib/libstdc++.so.6 #5 =C2=A00x2ef92402=
 in
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0IcedTeaPluginUtilities::invalidateInstance =
() from
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/local/openjdk6/jre/lib/IcedTeaPlugin.s=
o
>>>> ...
>>>>
>>>> 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.h=
tml
>>>>
>>>> You can find the patch and the sample code in the discussion above,=20
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 =3D cars.begin(); iter !=3D cars.end(); ) {
>>> if ((*iter).second =3D=3D modelName)
>>> =C2=A0cars.erase(iter++);
>>> else
>>> =C2=A0++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 pa=
tch=20
so
>> I hope it's accurate enough:
>>
>> =C2=A0 =C2=A0std::map<void*,NPP>::iterator iterator;
>> =C2=A0 =C2=A0for (iterator =3D instance_map->begin(); iterator !=3D inst=
ance_map->end();
>> iterator++)
>> =C2=A0 =C2=A0{
>> =C2=A0 =C2=A0 =C2=A0if ((*iterator).second =3D=3D instance)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0{
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 instance_map->erase((*iterator).first=
);
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>> =C2=A0 =C2=A0 }
>>
>> So, do you think, like Ed Schouten said, that there is a bug in the sour=
ce
>> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21554061.928151289040240274.JavaMail.defaultUser>