R: Re: R: IcedTea crashing again
Barbara
barbara.xxx1975 at libero.it
Fri Nov 5 08:57:44 UTC 2010
>>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
More information about the freebsd-java
mailing list