R: Re: R: IcedTea crashing again

[Barbara]

>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

I've tested the IcedTeaPlugin on 8_STABLE and it's not crashing.

Anyway I looked at the bt and I wrote a patch. You can find it here:
http://pastebin.com/b2KKFNSG

As risking a build failure (because of my patch) while building the entire 
port would have been too much time consuming, I rebuilt just the plugin,  with 
the following steps:

cd /usr/ports/java/openjdk6
make patch
cd work
patch < $MY_PATCH
cd icedtea6-1.9.1
mkdir -p build/lib
cd plugin/icedteanp

make -f /usr/ports/java/openjdk6/files/Makefile.plugin depend all \
DEBUG_FLAGS=-g \
LIBDIR=../../build/lib \
LIBOWN=`id -u` \
LIBGRP=`id -g` \
LOCALBASE=/usr/local \
JDK_UPDATE_VERSION=20 \
PLUGIN_VERSION="OpenJDK6 b20"

Then I renamed the installed IcedTeaPlugin.so appending .old and moved the new 
one in the same directory.
Now I can open many tabs with the demo applets without crashes after closing 
them.

Even if I'm not a C++ expert, the patch does make sense to me, as the iterator 
should be invalidated, and so not reused, after calling erase() as in the 
original code.
If I'm correct, I'm wondering why it's working on 8_STABLE.
Obviously, if you find the patch useful, feel free to use it at your will.

Thanks
Barbara