Backtrace:
#0 0x022bc800 in ?? ()
#1 0x00084232 in v8::internal::Invoke (construct=false, func=
{location_ = 0x822900}, receiver={location_ = 0x822908}, argc=0,
args=0x0, has_pending_exception=0x2fffce53) at /Users/jimt/src/v8_2/v8/
tools/../src/execution.cc:95
#2 0x000846a0 in v8::internal::Execution::Call (func={location_ =
0x822900}, receiver={location_ = 0x822908}, argc=0, args=0x0,
pending_exception=0x2fffce53) at /Users/jimt/src/v8_2/v8/tools/../src/
execution.cc:122
#3 0x00042aa6 in v8::internal::Genesis::CompileScriptCached (name=
{start_ = 0x1a6bf8 "native runtime.js", length_ = 17}, source=
{location_ = 0x821bb0}, cache=0x206b18, extension=0x0,
use_runtime_context=true) at /Users/jimt/src/v8_2/v8/tools/../src/
bootstrapper.cc:905
#4 0x00043050 in v8::internal::Genesis::CompileNative (name={start_ =
0x1a6bf8 "native runtime.js", length_ = 17}, source={location_ =
0x821bb0}) at /Users/jimt/src/v8_2/v8/tools/../src/bootstrapper.cc:853
#5 0x0004337e in v8::internal::Genesis::CompileBuiltin (index=5) at /
Users/jimt/src/v8_2/v8/tools/../src/bootstrapper.cc:842
#6 0x000439dc in v8::internal::Genesis::InstallNatives
(this=0x2fffd044) at /Users/jimt/src/v8_2/v8/tools/../src/
bootstrapper.cc:1075
#7 0x00043f20 in v8::internal::Genesis::Genesis (this=0x2fffd044,
global_object={location_ = 0x0}, global_template={val_ = 0x821ab4},
extensions=0x0) at /Users/jimt/src/v8_2/v8/tools/../src/
bootstrapper.cc:1506
#8 0x0004402e in v8::internal::Bootstrapper::CreateEnvironment
(global_object={location_ = 0x0}, global_template={val_ = 0x821ab4},
extensions=0x0) at /Users/jimt/src/v8_2/v8/tools/../src/
bootstrapper.cc:351
#9 0x00029f70 in v8::Context::New (extensions=0x0, global_template=
{val_ = 0x821a00}, global_object={val_ = 0x0}) at /Users/jimt/src/v8_2/
v8/tools/../src/api.cc:2493
Regs:
r0 0x22beaa0 36432544
r1 0x2801231 41947697
r2 0x2800a1d 41945629
r3 0x0 0
r4 0x22bc800 36423680
r5 0x0 0
r6 0x22beaa0 36432544
r7 0x2fffcdb8 805293496
r8 0x2801231 41947697
r9 0x8 8
r10 0x401930 4200752
r11 0x0 0
r12 0x22beaa0 36432544
sp 0x2fffcd44 805293380
lr 0x84233 541235
pc 0x22bc800 36423680
disass 0x22bc7B0 0x22bc810:
Dump of assembler code from 0x22bc7b0 to 0x22bc810:
0x022bc7b0: eoreq r3, r1, r8, ror r3
0x022bc7b4: eoreq r3, r1, r8, ror r3
0x022bc7b8: eoreq r3, r1, r4, ror #6
0x022bc7bc: eoreq r3, r1, r4, asr #6
0x022bc7c0: eoreq r3, r1, r8, ror r3
0x022bc7c4: svcvc 0x00071720
0x022bc7c8: svcvc 0x000b1708
0x022bc7cc: andeq r0, r0, r0
0x022bc7d0: andeq r0, r0, r0
0x022bc7d4: andeq r0, r0, r0
0x022bc7d8: andeq r0, r0, r0
0x022bc7dc: andeq r0, r0, r0
0x022bc7e0: mlseq r9, r1, r7, r4
0x022bc7e4: strdeq r0, [r0], -r8
0x022bc7e8: andeq r0, r0, r0
0x022bc7ec: andeq r0, r0, r0
0x022bc7f0: undefined instruction 0xfffffe08
0x022bc7f4: andeq r0, r0, r0, lsl #28
0x022bc7f8: andeq r0, r0, r0
0x022bc7fc: andeq r0, r0, r0
0x022bc800: nop (mov r0,r0)
0x022bc804: nop (mov r0,r0)
0x022bc808: nop (mov r0,r0)
Looks like the culprit is that undefined instruction at 0x022bc7f0.
The nop()s are mine, indicating the start of the JSEntryStub. Any
ideas?
.
On May 7, 10:55 am, Erik Corry <[email protected]> wrote:
> 2009/5/7 jimt <[email protected]>
>
>
>
>
>
>
>
> > Hi,
>
> > I'm building v8 for an ARM6 board, and things appear to run smoothly
> > up until the point where I call v8::Context::New(NULL,
> > api_callback_context_);
>
> > As you know, the creation of a new context forces the JS natives to be
> > compiled and run.
>
> > This process proceeds fine up until the point where the JSEntryStub is
> > called to invoke the compiled JS function. The code is generated by
> > JSEntryStub::GenerateBody.
>
> > Debugging this issue, I've noticed that even if
> > JSEntryStub::GenerateBody contains only a few nop()s, the crash still
> > occurs, leading me to believe that the issue has nothing to do with
> > the compiled JS function. The crash occurs at Invoke() in
> > execution.cc where CALL_GENERATED_CODE happens. I know the addresses
> > of the parameters are valid, as well as the address of the stub. (I
> > can inspect the memory at the entry stub address and see the
> > instructions put there by JSEntryStub::GenerateBody).
>
> > Everything appears fine from a method invocation standpoint as far as
> > I can tell. What gives?
>
> It would be interesting to see what gdb says. Try 'bt', 'info reg' and
> 'disass address address' where the two addresses are on either side of the
> PC when it crashes.
>
> Also, be sure to compile the VM in debug mode when testing. There are a ton
> of asserts that are compiled out in release mode and they can often give you
> a clue as to what is going wrong.
>
>
>
> > Thanks again.
>
> > .
>
> --
> Erik Corry, Software Engineer
> Google Denmark ApS. CVR nr. 28 86 69 84
> c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K,
> Denmark.
--~--~---------~--~----~------------~-------~--~----~
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
-~----------~----~----~----~------~----~------~--~---
