Date: Sat, 6 Nov 2010 11:33:31 +0100 From: Vlad Galu <dudu@dudu.ro> To: Barbara <barbara.xxx1975@libero.it> Cc: freebsd-current@freebsd.org Subject: Re: libstc++ (?) problem on CURRENT? Message-ID: <AANLkTiko%2BK5jDqM=rZRg7nFA-yFKUAtpgL2UKmsoYRDe@mail.gmail.com> In-Reply-To: <13873405.926621289039480757.JavaMail.defaultUser@defaultHost> References: <13873405.926621289039480757.JavaMail.defaultUser@defaultHost>
index | next in thread | previous in thread | raw e-mail
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> 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.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTiko%2BK5jDqM=rZRg7nFA-yFKUAtpgL2UKmsoYRDe>