2009/5/7 jimt <[email protected]> > > > 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? >
Looks to me like 0x022bc800 is not executable. Try checking /proc/<processnr>/maps . Perhaps your kernel is not honouring the executable bit in the allocation routines. > . > > 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. > > > -- 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 -~----------~----~----~----~------~----~------~--~---
