rekonq crashes on Toshiba AC100 (ARM) when viewing a page at openbenchmarks

[Ivan Zakharyaschev]

I'm using Ubuntu 12.04 for Toshiba AC100 (ARM).

I've installed rekonq.

When I begin to read the page http://openbenchmarking.org/result/1201241-AR-1201188TU67 (scroll it or pagedown further), rekonq crashes every time.

Perhaps, this has something to do with Java (I've noticed java was running, perhaps because there is a Java applet there).

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: rekonq 0.9.1-0ubuntu2
Uname: Linux 3.0.27-1-ac100 armv7l
ApportVersion: 2.0.1-0ubuntu11
Architecture: armhf
Date: Sat Jul 28 22:39:18 2012
SourcePackage: rekonq
UpgradeStatus: No upgrade log present (probably fresh install)

[Ivan Zakharyaschev (imz)]

Application: rekonq (0.9.1)
KDE Platform Version: 4.8.4 (4.8.4)
Qt Version: 4.8.1
Operating System: Linux 3.0.27-1-ac100 armv7l
Distribution: Ubuntu 12.04 LTS

-- Information about the crash:
- What I was doing when the application crashed:

I'm using the Ubuntu 12.04 distro for Toshiba AC100 (ARM).

Whenever I'm beginning to read a page at openbenchmarks (smth related with AC100 and ext4), rekonq crashes (possibly, at the moment when I try to scroll down, possibly with the pagedown key).

In the next start, since I want to continue reading this page, I reopen the last crashed session, and again rekonq crashes soon after I begin th reading (possibly, after I attempt to scroll down).

The crash can be reproduced every time.

-- Backtrace:
Application: rekonq (rekonq), signal: Segmentation fault
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[Current thread is 1 (Thread 0xb31e2000 (LWP 2841))]

Thread 10 (Thread 0xb1526420 (LWP 2842)):
#0 0xb6de5276 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#1 0xb6e544a8 in poll () from /lib/arm-linux-gnueabihf/libc.so.6
#2 0xb3b7922e in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#3 0xb3b7922e in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 9 (Thread 0xb0bc9420 (LWP 2843)):
#0 0xb3dfc608 in pthread_mutex_lock () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1 0xb6e65d8c in pthread_mutex_lock () from /lib/arm-linux-gnueabihf/libc.so.6
#2 0xb3ba18a2 in g_mutex_lock () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#3 0xb3b79264 in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#4 0xb3b79264 in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 8 (Thread 0xae9e8420 (LWP 2845)):
#0 0xb3e02384 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1 0xb3dfdff6 in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
#2 0xb6e65ca2 in pthread_cond_wait () from /lib/arm-linux-gnueabihf/libc.so.6
#3 0xb61dbc98 in WTF::TCMalloc_PageHeap::scavengerThread (this=0xb6c7cee4) at wtf/FastMalloc.cpp:2495
#4 0xb61dbd4e in WTF::TCMalloc_PageHeap::runScavengerThread (context=0xb6c7cee4) at wtf/FastMalloc.cpp:1618
#5 0xb3dfaed2 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#6 0xb6e5d058 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#7 0xb6e5d058 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 7 (Thread 0xae0af420 (LWP 2848)):
#0 0xb3b570c0 in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#1 0xb3ba18a2 in g_mutex_lock () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#2 0xb3b78d58 in g_main_context_query () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#3 0xb3b791ba in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#4 0xb3b791ba in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 6 (Thread 0xacb83420 (LWP 2849)):
#0 0xb3e02384 in __libc_do_s...

[Ivan Zakharyaschev (imz)]

Hmm, it crashed several times before, but on my last attempt, it didn't.

Perhaps the reason was that it was simply out of memory.

Perhaps, the messages rekonq printed in the terminal about Java were simply about it trying to use the installed Java plugin and discovering that something was wrong with it, and perhaps Java has no connection to the crashes.

[Ivan Zakharyaschev (imz)]

Hmm, it crashed several times before, but on my last attempt, it didn't.

Perhaps the reason was that it was simply out of memory.

Perhaps, the messages rekonq printed in the terminal about Java were simply about it trying to use the installed Java plugin and discovering that something was wrong with it, and perhaps Java has no connection to the crashes.

[Ivan Zakharyaschev (imz)]

So, the crash couldn't be reproduced the last time. And this was after I set up some more swap space (by creating swapfiles in the filesystems on some of the other bigger Toshiba AC100's factory partitions -- although this is not recommended because the memory will wear out quickly then).

[Ivan Zakharyaschev (imz)]

Maybe this is simply due to little memory on the system.

[Andrew-crouthamel (andrew-crouthamel)]

This bug has had its resolution changed, but accidentally has been left in NEEDSINFO status. I am thus closing this bug and setting the status as RESOLVED to reflect the resolution change.