Date: Tue, 2 Nov 2010 01:08:23 +0100 (CET) From: Barbara <barbara.xxx1975@libero.it> To: <jkim@FreeBSD.org> Cc: freebsd-java@FreeBSD.org Subject: R: Re: R: IcedTea crashing again Message-ID: <11663775.437861288656503416.JavaMail.defaultUser@defaultHost>
index | next in thread | raw e-mail
>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 <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 >> #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<nsRefPtr<imgCacheEntry>, std:: >> allocator<nsRefPtr<imgCacheEntry> > >::_M_insert_aux () from >> /usr/local/lib/firefox3/libxul.so >> #9 0x284b0598 in std::vector<nsRefPtr<imgCacheEntry>, std:: >> allocator<nsRefPtr<imgCacheEntry> > >::_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<nsRefPtr<imgCacheEntry>, std:: >> allocator<nsRefPtr<imgCacheEntry> > >::_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 Barbarahome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11663775.437861288656503416.JavaMail.defaultUser>