From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 10:44:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8B2E106566B for ; Sat, 6 Nov 2010 10:44:01 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from cp-out1.libero.it (cp-out1.libero.it [212.52.84.101]) by mx1.freebsd.org (Postfix) with ESMTP id 71C728FC0A for ; Sat, 6 Nov 2010 10:44:01 +0000 (UTC) Received: from wmail46 (172.31.0.236) by cp-out1.libero.it (8.5.115) (authenticated as barbara.xxx1975@libero.it) id 4AB2342317FE36A7; Sat, 6 Nov 2010 11:44:00 +0100 Message-ID: <21554061.928151289040240274.JavaMail.defaultUser@defaultHost> Date: Sat, 6 Nov 2010 11:44:00 +0100 (CET) From: Barbara To: MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.3.210.9 Cc: dudu@dudu.ro Subject: R: Re: libstc++ (?) problem on CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Barbara List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 10:44:02 -0000 >On Sat, Nov 6, 2010 at 11:31 AM, Barbara wrote= : >> >> >>>On Sat, Nov 6, 2010 at 10:57 AM, Barbara 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 >>>> #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::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