R: Re: R: IcedTea crashing again

[Jung-uk Kim]

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 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