On 05/24/13 14:59, Justin Lebar wrote:
This should be very easy to debug.
Just attach gdb to the relevant process (./run-gdb.sh attach PID --
you can find the pid by running adb shell b2g-ps), then break on
|read|, then you should quite quickly find out who's calling read in a
loop.
The real question will be why we get an infinite loop of EAGAIN's...
b2g has 36 threads running.. after setting a breakpoint on "read" i got
the thread.
this is the backtrace:
(gdb) bt
#0 read () at bionic/libc/arch-arm/syscalls/read.S:8
#1 0x41379de6 in pipeHandler (fd=35, data=<value optimized out>)
at /home/pancake/prg/B2G/gecko/widget/gonk/nsAppShell.cpp:101
#2 0x41379cbe in FdHandler::run (this=0x4391bca0, mayWait=<value
optimized out>)
at /home/pancake/prg/B2G/gecko/widget/gonk/nsAppShell.h:50
#3 nsAppShell::ProcessNextNativeEvent (this=0x4391bca0, mayWait=<value
optimized out>)
at /home/pancake/prg/B2G/gecko/widget/gonk/nsAppShell.cpp:733
#4 0x41397aae in nsBaseAppShell::DoProcessNextNativeEvent (this=0x23,
mayWait=128, recursionDepth=32)
at /home/pancake/prg/B2G/gecko/widget/xpwidgets/nsBaseAppShell.cpp:139
#5 0x41397b74 in nsBaseAppShell::OnProcessNextEvent (this=0x4391bca0,
thr=0x40309940, mayWait=false, recursionDepth=0)
at /home/pancake/prg/B2G/gecko/widget/xpwidgets/nsBaseAppShell.cpp:286
#6 0x4162ea52 in nsThread::ProcessNextEvent (this=0x40309940,
mayWait=false, result=0xbe932857)
at /home/pancake/prg/B2G/gecko/xpcom/threads/nsThread.cpp:600
#7 0x4160ed9e in NS_ProcessNextEvent (thread=0x4391bca0, mayWait=false)
at /home/pancake/prg/B2G/objdir-gecko/xpcom/build/nsThreadUtils.cpp:238
#8 0x413e83a8 in mozilla::ipc::MessagePump::Run (this=0x40302460,
aDelegate=0x4032e0c0)
at /home/pancake/prg/B2G/gecko/ipc/glue/MessagePump.cpp:82
#9 0x4165cdcc in MessageLoop::RunInternal (this=0x0)
at
/home/pancake/prg/B2G/gecko/ipc/chromium/src/base/message_loop.cc:219
#10 0x4165ce82 in MessageLoop::RunHandler (this=0x4032e0c0)
at
/home/pancake/prg/B2G/gecko/ipc/chromium/src/base/message_loop.cc:212
#11 MessageLoop::Run (this=0x4032e0c0) at
/home/pancake/prg/B2G/gecko/ipc/chromium/src/base/message_loop.cc:186
#12 0x41397568 in nsBaseAppShell::Run (this=0x4391bca0)
at /home/pancake/prg/B2G/gecko/widget/xpwidgets/nsBaseAppShell.cpp:163
#13 0x412f775c in nsAppStartup::Run (this=0x43a4b790)
at
/home/pancake/prg/B2G/gecko/toolkit/components/startup/nsAppStartup.cpp:269
#14 0x40c81de4 in XREMain::XRE_mainRun (this=0xbe932a14) at
/home/pancake/prg/B2G/gecko/toolkit/xre/nsAppRunner.cpp:3872
#15 0x40c845e6 in XREMain::XRE_main (this=0xbe932a14, argc=<value
optimized out>, argv=<value optimized out>,
aAppData=0x1f178) at
/home/pancake/prg/B2G/gecko/toolkit/xre/nsAppRunner.cpp:3939
#16 0x40c84748 in XRE_main (argc=1, argv=0xbe934bf4, aAppData=0x1f178,
aFlags=<value optimized out>)
at /home/pancake/prg/B2G/gecko/toolkit/xre/nsAppRunner.cpp:4140
#17 0x0000997e in do_main (argc=1, argv=0xbe934bf4) at
/home/pancake/prg/B2G/gecko/b2g/app/nsBrowserApp.cpp:168
#18 main (argc=1, argv=0xbe934bf4) at
/home/pancake/prg/B2G/gecko/b2g/app/nsBrowserApp.cpp:261
If I check in /proc i can see that the pair of this pipe is still alive:
root@android:/proc/991/fd # ls -l | grep 7045
lr-x------ root root 2013-05-24 15:47 35 -> pipe:[7045]
l-wx------ root root 2013-05-24 15:47 36 -> pipe:[7045]
Going up in the backtrace i found this:
(gdb) list
96 pipeHandler(int fd, FdHandler *data)
97 {
98 ssize_t len;
99 do {
100 char tmp[32];
101 len = read(fd, tmp, sizeof(tmp));
102 } while (len > 0);
103 }
104
105 struct Touch {
I have set a breakpoint on |write| with a condition of 'fd=36', but i
was unable to trigger it.. so i dont know what is this thread doing..
On Peak b2g takes 50% (because it's dual core) and runs a little better,
but some touch events are misstaken because of this intensive cpu use..
What else can I do? If you want to join #b2g we can discuss this better
in the irc.
Thanks
--pancake
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
