Date: Mon, 15 Nov 2010 23:43:14 +0100 (CET) From: Barbara <barbara.xxx1975@libero.it> To: <freebsd-java@FreeBSD.org> Subject: R: Re: R: IcedTea crashing again Message-ID: <24510497.2655081289860994407.JavaMail.defaultUser@defaultHost>
next in thread | raw e-mail | index | archive | help
>>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 > While waiting for feedback here, I've filed a bug in icedtea.classpath bugzilla, including a patch. http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=593 Barbara
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24510497.2655081289860994407.JavaMail.defaultUser>