2009/5/12  <[email protected]>:
>
> Thanks again Erik.  I tried removing it and it now crashes in src/
> objects-inl.h on line 1332.
>
> #
> # Fatal error in src/objects-inl.h, line 1332
> # CHECK(descriptor_number < number_of_descriptors()) failed
> #

That's reasonably strange.  A stack trace certainly would be helpful.
If you don't have gdb, but you do have glibc then perhaps you can use
the backtrace function (as used in OS::StackWalk in platform-linux.cc)
to hack up a quick stack-trace printer in V8_Fatal in checks.cc.  It
already tries to print a JS stack trace, but it doesn't attempt to
print a C/C+ stack trace.

>
> I haven't been able to see what the values of these are yet, but I am
> trying to track that down.
>
> On May 12, 1:58 pm, Erik Corry <[email protected]> wrote:
>> Oops the assertion is wrong.  Just delete the assertion.  I'll fix it ASAP.
>>
>> Hopefully a more significant assertion will turn up if you delete that one.
>>
>> 2009/5/12  <[email protected]>:
>>
>>
>>
>>
>>
>> > Thanks Erik.
>>
>> > I did manage to continue tracking down the issue last night and it
>> > turns out that there is an assertion occurring in assembler-asm.cc -
>> > line 612, which is in the function void Assembler::addrmod5(...)
>> > ----> ASSERT((instr & ~(CondMask | P | U | N | W | L)) == (B27 |
>> > B26));
>>
>> > Unfortunately, I am having trouble getting gdb to work properly on my
>> > hardware platform, so I am trying some alternative debugging
>> > methods.
>>
>> > Any ideas on the assertion?
>>
>> > Regards,
>> > John
>>
>> > On May 11, 4:35 pm, Erik Corry <[email protected]> wrote:
>> >> 2009/5/11  <[email protected]>:
>>
>> >> > Hi,
>>
>> >> > I have recently compiled the trunk version of the v8 javascript engine
>> >> > for the ARM processor under Linux and have run into an issue when
>> >> > executing the sample "shell" application from the command line.
>>
>> >> > I get the following output:
>> >> > "native runtime.js:612: <error>
>>
>> >> > Fatal error in v8::Context::New()
>> >> > Could not initialize environment
>>
>> >> Not a lot to go on here.  I would recommend you compile with
>> >> mode=debug on the scons command line to get all the slow assert code.
>> >> It sucks for performance but it's great for debugging.  If you get a
>> >> failed assert, then run in gdb and use bt to see where it is
>> >> happening.
>>
>> >> > "
>> >> > ./shell --help works fine.
>>
>> >> > The target platform is an ARM11 with the armv6 instruction set.  Linux
>> >> > kernel is 2.6.14.  gcc toolchain is 3.4.0.
>>
>> >> > To compile I did the following:
>> >> > $ scons toolchain=gcc arch=arm library=static os=linux importenv=PATH
>> >> > sample=shell
>> >> > where:
>> >> > CC="arm-linux-gcc"
>> >> > CXX="arm-linux-g++"
>> >> > RANLIB="arm-linux-ranlib"
>> >> > AR="arm-linux-ar"
>>
>> >> > Thanks for your time and I look forward to hearing any ideas on how to
>> >> > resolve this issue.
>>
>> >> > Regards,
>> >> > John
>>
>> >> --
>> >> 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.
> >
>



-- 
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to