R: Re: R: IcedTea crashing again

[Jung-uk Kim]

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

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