Date: Fri, 5 Nov 2010 09:57:42 +0100 (CET) From: Barbara <barbara.xxx1975@libero.it> To: <freebsd-java@FreeBSD.org> Subject: R: Re: R: IcedTea crashing again Message-ID: <7706560.762491288947462086.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 > Looking at the code again, there was something I was not sure about. So, I wrote a simple test with a function which doing more or less the same thing you can see in invalidateInstance in IcedTeaPluginUtils.cc. I don't know C++ and I had just rudiments of C some years ago, so if there is something wrong with the code "invalidating" the test, please let me know. Here's the code (http://pastebin.com/Amk4UJ0g): -------------------------------------------------------------------------------- #include <map> #include <string> #include <cstring> #include <iostream> std::map<const char*, const char*> cars; void fillCars() { cars["nissan"] = "micra"; cars["ford"] = "ka"; cars["toyota"] = "yaris"; cars["fiat"] = "punto"; cars["volkswagen"] = "fox"; } void printCars() { std::map<const char*, const char*>::iterator iter; for (iter = cars.begin(); iter != cars.end(); iter++) { std::cout << (*iter).first << " "; std::cout << (*iter).second << std::endl; } } void removeModel(const char * modelName) { std::map<const char*, const char*>::iterator iter; for (iter = cars.begin(); iter != cars.end(); iter++) { if ((*iter).second == modelName) { std::cout << modelName << " FOUND -> erase" << std::endl; cars.erase((*iter).first); } } } int main() { fillCars(); std::cout << "--> PRINTING CARS" << std::endl; printCars(); std::cout << std::endl; const char* punto[] = {"punto"}; std::cout << "--> REMOVING MODEL: " << (*punto) << std::endl; removeModel(*punto); std::cout << std::endl; std::cout << "--> PRINTING CARS" << std::endl; printCars(); std::cout << std::endl; } -------------------------------------------------------------------------------- Build it with: g++ -g -o cars cars.cc Running it on 8_STABLE i386 it works without errors. On 9.0-CURRENT i386, I get a "Segmentation fault: 11 (core dumped)" when erase() is invoked. The backtrace: #0 0x280d11b2 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6 #1 0x080499cb in std::_Rb_tree_iterator<std::pair<char const* const, char const*> >::operator++ (this=0xbfbfe8d0) at stl_tree.h:191 #2 0x08048c8b in removeModel (modelName=0x804a4a6 "punto") at cars.cc:32 #3 0x08048ec9 in main () at cars.cc:52 which looks similar to the one I'm getting from the IcedTea plugin. Is there something wrong on CURRENT? Can someone test the code on CURRENT X86_64? Thanks Barbara
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7706560.762491288947462086.JavaMail.defaultUser>