Description of problem: firefox freezes with a trace that I attach. I still haven't understood what causes it to freeze, it seems to be random. It doesn't really crashes, but is left with an empty window. There is a trace on the console when firefox is launched on the command line. The trace is always the same. It happens very frequently. In the trace there are reference to hunspell, so maybe the bug is in hunspell. I haven't found the same bug already entered which is a bit strange, maybe there is something in my setup that could explain that I am the only one seeing it, but I don't know what it could be. I tried to get a better backtrace in gdb, but when launched in gdb (with firefox -g) there is no problem... Maybe it is because it is slowed down? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 306250 [details] glibc trace associated with the freeze
Happens reliably for me when opening http://einestages.spiegel.de/static/topicalbumbackground/1771/die_ahnen_von_star_w Happens even when firefox is started in safe-mode
Well, bugzilla (or konqueror) munges long URLs. So this is the same one: http://tinyurl.com/4pbysr
workaround: downgrade your sqlite copy to 3.5.4
That didn't worked. I still get a similr trace, I attach it.
Created attachment 306321 [details] trace with sqlite 3.5.4
Er, sorry, meant to say to downgrade hunspell (which other apps will complain about likely.. but it will fix firefox at least.)
xulrunner requires libhunspell-1.2.so.0 provided by hunspell-1.2.2, the previous version is 1.2.1 which provides libhunspell.so.1, so xulrunner will also complain. I can do a compat package for hunspell (parallel installable) and rebuild xulrunner, but I am not sure it is worth it, hopefully this bug will be fixed soon.
*** This bug has been marked as a duplicate of 447444 ***