From owner-freebsd-java@FreeBSD.ORG Tue Nov 2 15:01:05 2010 Return-Path: Delivered-To: freebsd-java@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 8D8361065675; Tue, 2 Nov 2010 15:01:05 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Barbara Date: Tue, 2 Nov 2010 11:00:55 -0400 User-Agent: KMail/1.6.2 References: <11663775.437861288656503416.JavaMail.defaultUser@defaultHost> In-Reply-To: <11663775.437861288656503416.JavaMail.defaultUser@defaultHost> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011021100.58041.jkim@FreeBSD.org> Cc: freebsd-java@FreeBSD.org Subject: Re: R: Re: R: IcedTea crashing again X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 15:01:05 -0000 On Monday 01 November 2010 08:08 pm, Barbara wrote: > >On Monday 01 November 2010 06:30 pm, Barbara wrote: > >> >On Monday 01 November 2010 01:57 pm, Barbara wrote: > >> >> >After updating to openjdk6 b20_4, Firefox is crashing again > >> >> > closing a window running an applet. > >> >> >Just like before the fixes made on Sept. 23. > >> >> > >> >> As I noticed that it is crashing only on CURRENT, I have a > >> >> suspect... > >> > > >> >Sorry, I cannot reproduce it on amd64 CURRENT. FYI, David Xu > >> > has been busy reshuffling libthr recently. Maybe your kernel, > >> > libthr, and/or binaries from ports are out of sync? > >> > > >> >> Could it be caused by SVN rev 213098? > >> >> http://svn.freebsd.org/viewvc/base/head/sys/i386/conf/GENERIC > >> >>? r1=210947&r2=213098 > >> >> Should I kldload sem again? > >> > > >> >Why don't you try for yourself and let us know? :-P > >> > >> I've tried kldloading sem (on i386) and I was pretty sure it was > >> working. I did that while rebuilding world+kernel after running > >> csup. But at reboot it's segfaulting no matter if sem is loaded > >> or not. So now I'm not so sure. > >> > >> All my ports are updated. > > > >According to the commit log, sem.ko is only required for *old* > >binaries, i.e., updating ports may not fix the problem but you may > >have to *rebuild* every port from scratch to prove or disprove it, > >unfortunately. :-( > > I was thinking about that. > Anyway, many ports were built after that, including Firefox and > OpenJDK. And kldloading sem doesn't fix that. Maybe my "successful" > tests were just wrong. > > >> I can crash it regularly loading a demo applet (e.g. ArcTest in > >> /usr/local/openjdk6/demo/applets) in a tab and then closing the > >> tab. If it could be of any help, I'm adding an excerpt from the > >> backtrace I'm getting: > >> > >> Core was generated by `firefox-bin'. > >> Program terminated with signal 11, Segmentation fault. > >> ... > >> #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 > >> #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 > >> #6 0x2efa17b0 in ITNP_Destroy () from > >> /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so > >> #7 0x28b5d776 in ffi_call_SYSV () from > >> /usr/local/lib/firefox3/libxul.so #8 0x284b023b in > >> std::vector, std:: > >> allocator > >::_M_insert_aux () from > >> /usr/local/lib/firefox3/libxul.so > >> #9 0x284b0598 in std::vector, std:: > >> allocator > >::_M_insert_aux () from > >> /usr/local/lib/firefox3/libxul.so > >> #10 0x28d721c3 in NS_GetComponentManager_P () from > >> /usr/local/lib/firefox3/libxul.so > >> #11 0x28d339d3 in nsPrintSession::Release () from > >> /usr/local/lib/firefox3/libxul.so > >> #12 0x28c6ede7 in JSD_DebuggerOnForUser () from > >> /usr/local/lib/firefox3/libxul. so > >> #13 0x28ae42df in std::vector, std:: > >> allocator > >::_M_insert_aux () from > >> /usr/local/lib/firefox3/libxul.so > >> #14 0x2823bc84 in XRE_main () from > >> /usr/local/lib/firefox3/libxul.so > > > >This trace looks almost identical as before, i.e., without the > >patch. :-/ > > > >Jung-uk Kim > > Are you talking about the patch you added to the previous version? > The one I was talking about on my first post? No, I was talking about the patch in the ports now. Jung-uk Kim > If you create a patch for the new version, I can test it. > I can try applying it to new current version, but I'm not sure I'll > find any time before the week end. > > Thanks > Barbara