Thanks Vyacheslav,
Thing #1: I do agree with you, I need to review my own code and track my
objects better and not try to ask for Length() on a dead object. Bummer.
Thing #2: Why did Length() method fail to detect IsDeadCheck()? It seems
that my `this` pointer is a corrupted form of kZapValue. I have
this=0xdeadbeedbeadbe05
instead of deadbeeddeadbeed. I think the poignant question here is, "who
corrupted my kZapValue?". But that is probably very difficult to answer.
Bummer^2.
--
Ricky Charlet
See Y' Later
On Fri Apr 22 7:53 , Vyacheslav Egorov sent:
>Hi Ricky,
>
>Yeah, that looks like a dead object.
>
>I would suspect a Handle-misuse somewhere. However it is hard to
>diagnose. You need to look through your code and check that you have
>HandleScopes in proper places, that you use Persistent handles where
>appropriate and does not simply return Local handles without properly
>closing containing HandleScope.
>
>--
>Vyacheslav Egorov
>
>
>
>On Thu, Apr 21, 2011 at 8:04 PM, Ricky Charlet rchar...@speakeasy.net> wrote:
>> BTW,
>> This is trunk code from 4/21.
>>
>> On Apr 21, 10:51 am, Ricky Charlet rchar...@speakeasy.net> wrote:
>>> Howdy,
>>> I'm new to v8. However my company has been using v8 since 1.3.
>>> I've got the task to investigate modernizing it. So I've got two
>>> variables in play here... I'm changing from v8-1.3 to v8-3.3.1 and
>>> also changing from a 32bit architecture to a 64 bit architecture. I'm
>>> suspecting the 64 bit change is causing my crash for the modest reason
>>> that there are so many casts in my path to the crash.
>>>
>>> OK, So I have v8-3.3.1 complied with
>>> `scons arch=x64 arch_size=64 mode=debug` and I've statically linked my
>>> code to libv8_g.a (renamed to libv8.a).
>>>
>>> My program is calling v8::Array::Length in api.cc. I guess I'm
>>> calling length on a dead object because of the "deadbee..." in
>>> "#1 0x00000000006034e0 in v8::internal::HeapObject::map
>>> (this=0xdeadbeedbeadbe05) at src/objects-inl.h:1176"
>>>
>>> I've noticed many casts up and down the frame0 through frame5 stuff.
>>> That may or may not be germane to the issue and I did not ponder them
>>> very deeply before I just ran to this list to see if anyone else wants
>>> to chime in with some experience and wisdom here.
>>>
>>> Here is my gdb stack trace.
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x0000000000603536 in v8::internal::HeapObject::map_word
>>> (this=0xdeadbeedbeadbe05)
>>> at src/objects-inl.h:1186
>>> 1186 return MapWord(reinterpret_cast(READ_FIELD(this,
>>> kMapOffset)));
>>> (gdb) bt
>>> #0 0x0000000000603536 in v8::internal::HeapObject::map_word (
>>> this=0xdeadbeedbeadbe05) at src/objects-inl.h:1186
>>> #1 0x00000000006034e0 in v8::internal::HeapObject::map
>>> (this=0xdeadbeedbeadbe05)
>>> at src/objects-inl.h:1176
>>> #2 0x000000000060224a in v8::internal::Object::IsHeapNumber() ()
>>> #3 0x00000000006026ae in v8::internal::Object::IsNumber() ()
>>> #4 0x00000000006031f6 in v8::internal::Object::Number() ()
>>> #5 0x00000000005fac84 in v8::Array::Length (this=0x147ded8) at src/
>>> api.cc:4297
>>> #6 0x00000000004566c5 in mus_parser::_create_step
>>> (this=0x7fffffffdff0, obj=...)
>>> at ../../mus_parser_gen.cc:2840
>>> #7 0x000000000043f9d2 in mus_parser::_create_scenario
>>> (this=0x7fffffffdff0, obj=...)
>>> at ../../mus_parser.cc:276
>>> #8 0x0000000000442764 in mus_parser::load (this=0x7fffffffdff0,
>>> musl=...)
>>> at ../../mus_parser.cc:681
>>> #9 0x0000000000480ea6 in mus_test_builder::make_scenario
>>> (this=0x7fffffffe990,
>>> scheduler=0x7fffffffe820, obj=..., error=...) at ../../
>>> mus_test_builder.cc:200
>>> #10 0x000000000048014d in mus_test_builder::make_track
>>> (this=0x7fffffffe990,
>>> scheduler=0x7fffffffe820, obj=..., error=...) at ../../
>>> mus_test_builder.cc:141
>>> #11 0x000000000047ff1f in mus_test_builder::build_test_internal (
>>> this=0x7fffffffe990, scheduler=0x7fffffffe820, json=...,
>>> error=...)
>>> at ../../mus_test_builder.cc:125
>>> #12 0x000000000047fb8e in mus_test_builder::build_test
>>> (this=0x7fffffffe990,
>>> scheduler=0x7fffffffe820, json=..., error=...) at ../../
>>> mus_test_builder.cc:73
>>> #13 0x000000000040e3a5 in execute_json (opts=...) at ../../testr.cc:
>>> 552
>>> #14 0x000000000040e816 in main (argc=0, argv=0x7fffffffec70) at ../../
>>> testr.cc:621
>>> (gdb) list
>>> 1181 set_map_word(MapWord::FromMap(value));
>>> 1182 }
>>> 1183
>>> 1184
>>> 1185 MapWord HeapObject::map_word() {
>>> 1186 return MapWord(reinterpret_cast(READ_FIELD(this,
>>> kMapOffset)));
>>> 1187 }
>>> 1188
>>> 1189
>>> 1190 void HeapObject::set_map_word(MapWord map_word) {
>>> (gdb) :q
>>> Undefined command: "". Try "help".
>>> (gdb) frame 6
>>> #6 0x00000000004566c5 in mus_parser::_create_step
>>> (this=0x7fffffffdff0, obj=...)
>>> at ../../mus_parser_gen.cc:2840
>>> 2840 for (uint32_t n=0; nLength(); ++n) {
>>> (gdb) l
>>> 2835 if (v_payload == 0) goto bummer;
>>> 2836 v->payload(v_payload);
>>> 2837 }
>>> 2838
>>> 2839 Handle variables = _array(obj, "variables");
>>> 2840 for (uint32_t n=0; nLength(); ++n) {
>>> 2841 Handle variable_obj = _object(variables, n);
>>> 2842 mus_step_variable *variable = _create_variable(v,
>>> variable_obj);
>>> 2843 if (variable == 0) goto bummer;
>>> 2844 v->variables(variable);
>>>
>>> Hopefully,
>>> Ricky Charlet
>>
>> --
>> v8-users mailing list
>> v8-users@googlegroups.com
>> http://groups.google.com/group/v8-users
>>
>
>--
>v8-users mailing list
>v8-users@googlegroups.com
>http://groups.google.com/group/v8-users
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
