From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 10:35:33 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 01BCB106566C for ; Sat, 6 Nov 2010 10:35:33 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 95A638FC13 for ; Sat, 6 Nov 2010 10:35:32 +0000 (UTC) Received: by wyb34 with SMTP id 34so1883290wyb.13 for ; Sat, 06 Nov 2010 03:35:31 -0700 (PDT) Received: by 10.216.26.194 with SMTP id c44mr2892561wea.104.1289039730703; Sat, 06 Nov 2010 03:35:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.175.66 with HTTP; Sat, 6 Nov 2010 03:34:50 -0700 (PDT) In-Reply-To: References: <19821003.923081289037424002.JavaMail.defaultUser@defaultHost> From: Vlad Galu Date: Sat, 6 Nov 2010 11:34:50 +0100 Message-ID: To: Barbara Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: libstc++ (?) problem on CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list 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:35:33 -0000 On Sat, Nov 6, 2010 at 11:32 AM, Vlad Galu wrote: > On Sat, Nov 6, 2010 at 11:11 AM, Vlad Galu 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 segfaul= ting on >>> CURRENT, considering also that AFAIK the gcc version in both the base s= ystems >>> is the same. >>> >>> In the part of the code causing the crash, a std::map is read with an i= terator >>> in a for loop, and if a condition is met, an entry is erased. >>> The following is the bt I'm getting: >>> #0 =A00x29e36247 in kill () from /lib/libc.so.7 >>> #1 =A00x29e361a6 in raise () from /lib/libc.so.7 >>> #2 =A00x282424f6 in XRE_LockProfileDirectory () from >>> =A0 =A0 =A0 =A0/usr/local/lib/firefox3/libxul.so >>> #3 =A0 >>> #4 =A00x29c8f1b2 in std::_Rb_tree_increment () from >>> =A0 =A0 =A0 =A0/usr/lib/libstdc++.so.6 #5 =A00x2ef92402 in >>> =A0 =A0 =A0 =A0IcedTeaPluginUtilities::invalidateInstance () from >>> =A0 =A0 =A0 =A0/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 w= orking. >>> 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.ht= ml >>> >>> You can find the patch and the sample code in the discussion above, any= way 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(); ) { >> =A0if ((*iter).second =3D=3D modelName) >> =A0cars.erase(iter++); >> =A0else >> =A0++iter; >> } >> -- and here -- >> >> In this example, you first increment the iterator and then erase its >> previous value. > > Or, better yet: cars.erase("punto"); I see no reason in iterating > through the whole map unless you want to relate the deletion to the > matched type, in which case you should use the previous example. > Sorry, I meant mapped type. --=20 Good, fast & cheap. Pick any two.