| arm: chromium renderer snaps instantly with "pure virtual function called" in ubuntu/lucid | ||||||
| Reported by a...@jwsdot.com, Dec 23 2009 | Back to list | |||||
Chrome Version : 4.0.279.0~svn20091222r35149-0ubuntu1 (fta packages) gcc --version gcc (Ubuntu 4.4.2-6ubuntu1) 4.4.2 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. starting chromium built with armv7=0 (lucid has no neon support in kernel), but with arm_thumb=1 snaps with "pure virtual function called". in single process mode i see infinite stack like: #5019 0x40d89aec in *__GI_abort () at abort.c:92 #5020 0x40d89aec in *__GI_abort () at abort.c:92 #5021 0x40d89aec in *__GI_abort () at abort.c:92 #5022 0x40d89aec in *__GI_abort () at abort.c:92 guess process is trashed badly, but here some more gdb still: (gdb) info registers r0 0x0 0 r1 0x61a4 24996 r2 0x6 6 r3 0x61a4 24996 r4 0x6 6 r5 0x40e48000 1088716800 r6 0x44f6b028 1157017640 r7 0x10c 268 r8 0x44f6f410 1157035024 r9 0x44f6b0d0 1157017808 r10 0x40e48bec 1088719852 r11 0x1 1 r12 0x0 0 sp 0x44f6b028 0x44f6b028 lr 0x40d872bd 1087926973 pc 0x40d872ee 0x40d872ee <*__GI_raise+58> fps 0x0 0 cpsr 0x20000030 536870960 0x40d872b4 <*__GI_raise+0>: push {r4, r5, r6, lr} 0x40d872b6 <*__GI_raise+2>: mov r4, r0 0x40d872b8 <*__GI_raise+4>: blx 0x40d78630 <__aeabi_read_tp> 0x40d872bc <*__GI_raise+8>: sub sp, #8 0x40d872be <*__GI_raise+10>: sub.w r2, r0, #1216 ; 0x4c0 0x40d872c2 <*__GI_raise+14>: ldr r3, [r2, #104] ; 0x68 0x40d872c4 <*__GI_raise+16>: ldr r0, [r2, #108] ; 0x6c 0x40d872c6 <*__GI_raise+18>: cmp r3, #0 0x40d872c8 <*__GI_raise+20>: bne.n 0x40d872fe <*__GI_raise+74> 0x40d872ca <*__GI_raise+22>: movs r3, #224 ; 0xe0 0x40d872cc <*__GI_raise+24>: mov r6, sp 0x40d872ce <*__GI_raise+26>: str r3, [sp, #0] 0x40d872d0 <*__GI_raise+28>: str r7, [r6, #4] 0x40d872d2 <*__GI_raise+30>: ldr r7, [r6, #0] 0x40d872d4 <*__GI_raise+32>: svc 0 0x40d872d6 <*__GI_raise+34>: ldr r7, [r6, #4] 0x40d872d8 <*__GI_raise+36>: mov r3, r0 0x40d872da <*__GI_raise+38>: str r0, [r2, #104] ; 0x68 0x40d872dc <*__GI_raise+40>: mov.w r2, #268 ; 0x10c 0x40d872e0 <*__GI_raise+44>: mov r6, sp 0x40d872e2 <*__GI_raise+46>: str r2, [sp, #0] 0x40d872e4 <*__GI_raise+48>: mov r1, r3 0x40d872e6 <*__GI_raise+50>: mov r2, r4 0x40d872e8 <*__GI_raise+52>: str r7, [r6, #4] 0x40d872ea <*__GI_raise+54>: ldr r7, [r6, #0] 0x40d872ec <*__GI_raise+56>: svc 0 0x40d872ee <*__GI_raise+58>: ldr r7, [r6, #4] 0x40d872f0 <*__GI_raise+60>: cmn.w r0, #4096 ; 0x1000 0x40d872f4 <*__GI_raise+64>: mov r1, r0 0x40d872f6 <*__GI_raise+66>: bhi.n 0x40d8730c <*__GI_raise+88> 0x40d872f8 <*__GI_raise+68>: mov r0, r1 0x40d872fa <*__GI_raise+70>: add sp, #8 0x40d872fc <*__GI_raise+72>: pop {r4, r5, r6, pc} 0x40d872fe <*__GI_raise+74>: cmp r0, #0 0x40d87300 <*__GI_raise+76>: bgt.n 0x40d872dc <*__GI_raise+40> 0x40d87302 <*__GI_raise+78>: bic.w r2, r0, #2147483648 ; 0x80000000 0x40d87306 <*__GI_raise+82>: cbnz r2, 0x40d8734e <*__GI_raise+154> 0x40d87308 <*__GI_raise+84>: mov r0, r3 0x40d8730a <*__GI_raise+86>: b.n 0x40d872dc <*__GI_raise+40> 0x40d8730c <*__GI_raise+88>: ldr r5, [pc, #68] ; (0x40d87354 <*__GI_raise+160>) 0x40d8730e <*__GI_raise+90>: nop 0x40d87310 <*__GI_raise+92>: add r2, pc, #0 ; (adr r2, 0x40d87314 <*__GI_raise+96>) 0x40d87312 <*__GI_raise+94>: blx 0x40d78630 <__aeabi_read_tp> 0x40d87316 <*__GI_raise+98>: negs r1, r1 0x40d87318 <*__GI_raise+100>: ldr r5, [r5, r2] 0x40d8731a <*__GI_raise+102>: adds r2, r0, r5 0x40d8731c <*__GI_raise+104>: cmp r1, #38 ; 0x26 0x40d8731e <*__GI_raise+106>: str r1, [r0, r5] 0x40d87320 <*__GI_raise+108>: it ne 0x40d87322 <*__GI_raise+110>: movne.w r1, #4294967295 0x40d87326 <*__GI_raise+114>: bne.n 0x40d872f8 <*__GI_raise+68> 0x40d87328 <*__GI_raise+116>: mov r0, r3 0x40d8732a <*__GI_raise+118>: mov r1, r4 0x40d8732c <*__GI_raise+120>: movs r3, #238 ; 0xee 0x40d8732e <*__GI_raise+122>: mov r6, sp 0x40d87330 <*__GI_raise+124>: str r3, [sp, #0] 0x40d87332 <*__GI_raise+126>: str r7, [r6, #4] 0x40d87334 <*__GI_raise+128>: ldr r7, [r6, #0] 0x40d87336 <*__GI_raise+130>: svc 0 0x40d87338 <*__GI_raise+132>: ldr r7, [r6, #4] 0x40d8733a <*__GI_raise+134>: cmn.w r0, #4096 ; 0x1000 0x40d8733e <*__GI_raise+138>: it ls 0x40d87340 <*__GI_raise+140>: movls r1, r0 0x40d87342 <*__GI_raise+142>: bls.n 0x40d872f8 <*__GI_raise+68> 0x40d87344 <*__GI_raise+144>: negs r0, r0 0x40d87346 <*__GI_raise+146>: mov.w r1, #4294967295 0x40d8734a <*__GI_raise+150>: str r0, [r2, #0] 0x40d8734c <*__GI_raise+152>: b.n 0x40d872f8 <*__GI_raise+68> 0x40d8734e <*__GI_raise+154>: negs r0, r0 0x40d87350 <*__GI_raise+156>: b.n 0x40d872dc <*__GI_raise+40> 0x40d87352 <*__GI_raise+158>: nop 0x40d87354 <*__GI_raise+160>: lsrs r0, r5, #25 0x40d87356 <*__GI_raise+162>: lsls r4, r1, #0
Comment 1
by
f...@sofaraway.org,
Dec 23 2009
,
Dec 29 2009
update: chromium-browser works for some pages; seems to pages without javascript work well (e.g. www.debian.org), while everything with javascript snaps (www.google.com). Saw that we build using v8_use_snapshot=false on arm; will try a build with v8_use_snapshot=true next.
,
Dec 29 2009
v8_use_snapshot=true fails to build natively still. filed http://code.google.com/p/chromium/issues/detail?id=31274 for that
,
Jan 1 2010
ok more playing around, this goes away by using one of: a) gcc-4.3 everywhere b) gcc 4.4 with -fstrict-aliasing in v8/
,
Jan 1 2010
Surely you mean -fno-strict-aliasing in v8? And that should be automatically set based on gcc_version=44 which in turn is set by build/compiler_version.sh (but perhaps that doesn't work well for cross compilation??)
,
Jan 2 2010
no ... i really ment what i said in b). -fno-strict-aliasing causes these issues on armel. without that I get a usable browser ;)
,
Jan 2 2010
found the gcc bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41354 seems its fixed in snapshot and a commit was identified: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41354#c8 so ... from what i understand we can either _not_ use that on armel or add -fno-tree- sink ... i will kick off a build with the latter on monday.
,
Jan 27 2010
Assigning this to the ARM man for question-asking/bug-closing decision.
,
Jun 24 2010
,
Jan 11 2011
What is the final solution for this issue?
,
Mar 10 2013
,
Oct 2 2015
This issue likely requires triage. The current issue owner may be inactive (i.e. hasn't fixed an issue in the last 30 days or commented in this particular issue in the last 90 days). It has also not been modified in a year (prior to this update). Thanks for helping out! -Anthony |
||||||
| ► Sign in to add a comment | ||||||