R: Re: R: IcedTea crashing again

[Barbara]

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