From owner-freebsd-java@FreeBSD.ORG Tue Nov 2 00:09:27 2010 Return-Path: Delivered-To: freebsd-java@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B0E81065695 for ; Tue, 2 Nov 2010 00:09:27 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from cp-out4.libero.it (cp-out4.libero.it [212.52.84.104]) by mx1.freebsd.org (Postfix) with ESMTP id 06F248FC16 for ; Tue, 2 Nov 2010 00:09:26 +0000 (UTC) Received: from wmail60 (172.31.0.57) by cp-out4.libero.it (8.5.107) (authenticated as barbara.xxx1975@libero.it) id 4CCF0A0E000291FF for freebsd-java@FreeBSD.org; Tue, 2 Nov 2010 01:09:25 +0100 Message-ID: <30009308.437901288656565739.JavaMail.defaultUser@defaultHost> Date: Tue, 2 Nov 2010 01:09:25 +0100 (CET) From: Barbara To: MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 82.57.159.3 Cc: Subject: R: Re: R: IcedTea crashing again X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Barbara List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 00:09:27 -0000 >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? 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