Eclipse V8 debugger partially operational

54 views
Skip to first unread message

Zoka

unread,
Feb 13, 2010, 1:36:43 PM2/13/10
to nodejs
Hi all,

The Eclipse based V8 debugger (http://code.google.com/p/
chromedevtools/) seems to be partially working as is when configured
for standalone V8 target on port 5858 and when node is started with --
debug option. It is possible to suspend /resume execution and browse
remote script files. However, hitting the break point results in
crash.

Joe Developer

unread,
Feb 13, 2010, 2:25:43 PM2/13/10
to nod...@googlegroups.com
Thats pretty awesome. Who uses eclipse? 
/me ducks 
 
--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.


Elijah Insua

unread,
Feb 13, 2010, 3:08:38 PM2/13/10
to nod...@googlegroups.com
On Sat, Feb 13, 2010 at 2:25 PM, Joe Developer <joe.d.d...@gmail.com> wrote:


On Sun, Feb 14, 2010 at 1:36 AM, Zoka <ztom...@gmail.com> wrote:
Hi all,

The Eclipse based V8 debugger   (http://code.google.com/p/
chromedevtools/
)  seems to be partially working as is when configured
for standalone V8 target on port 5858 and when node is started with --
debug option. It is possible to suspend /resume execution and browse
remote script files. However, hitting the break point results in
crash.

Thats pretty awesome. Who uses eclipse? 
/me ducks 
 
I've been known to, heh heh.  So it looks like it's hitting a segmentation fault, very interesting.

Joe Developer

unread,
Feb 13, 2010, 3:13:18 PM2/13/10
to nod...@googlegroups.com

Elijah Insua

unread,
Feb 13, 2010, 3:24:52 PM2/13/10
to nod...@googlegroups.com
On Sat, Feb 13, 2010 at 3:13 PM, Joe Developer <joe.d.d...@gmail.com> wrote:


On Sun, Feb 14, 2010 at 3:08 AM, Elijah Insua <tmp...@gmail.com> wrote:


On Sat, Feb 13, 2010 at 2:25 PM, Joe Developer <joe.d.d...@gmail.com> wrote:


On Sun, Feb 14, 2010 at 1:36 AM, Zoka <ztom...@gmail.com> wrote:
Hi all,

The Eclipse based V8 debugger   (http://code.google.com/p/
chromedevtools/
)  seems to be partially working as is when configured
for standalone V8 target on port 5858 and when node is started with --
debug option. It is possible to suspend /resume execution and browse
remote script files. However, hitting the break point results in
crash.

Thats pretty awesome. Who uses eclipse? 
/me ducks 
 
I've been known to, heh heh.  So it looks like it's hitting a segmentation fault, very interesting.

looks very pokable.  

Just incase anyone was curious:

tmpvar@tmpvar:~$ gdb --args node --debug workspace/v8DebuggerTest/test.js
GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/node...done.
(gdb) run
Starting program: /usr/local/bin/node --debug workspace/v8DebuggerTest/test.js
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffd2e61910 (LWP 5562)]
debugger listening on port 5858
Use 'd8 --remote_debugger' to access it.
[New Thread 0x7ffff7ff7910 (LWP 5563)]
[New Thread 0x7ffff7e2d910 (LWP 5564)]
Server running at http://127.0.0.1:8000/
[New Thread 0x7fffd2660910 (LWP 5571)]

Program received signal SIGSEGV, Segmentation fault.
0x00000000005596b8 in v8::internal::Runtime_GetScopeCount(v8::internal::Arguments) ()
(gdb) where
#0  0x00000000005596b8 in v8::internal::Runtime_GetScopeCount(v8::internal::Arguments) ()
#1  0x00007fffd2ea622a in ?? ()
#2  0x00007fffd1e2d109 in ?? ()
#3  0x00007fffd2ea61c1 in ?? ()
#4  0x00007fffffff9ae0 in ?? ()
#5  0x00007fffffff9b28 in ?? ()
#6  0x00007fffd2efdef4 in ?? ()
#7  0x0000000000000000 in ?? ()
(gdb)
 

Zoka

unread,
Feb 13, 2010, 4:36:31 PM2/13/10
to nodejs

On Feb 14, 7:24 am, Elijah Insua <tmp...@gmail.com> wrote:


> On Sat, Feb 13, 2010 at 3:13 PM, Joe Developer <joe.d.develo...@gmail.com>wrote:
>
>
>
>
>
> > On Sun, Feb 14, 2010 at 3:08 AM, Elijah Insua <tmp...@gmail.com> wrote:
>

> >> On Sat, Feb 13, 2010 at 2:25 PM, Joe Developer <joe.d.develo...@gmail.com
> >> > wrote:


>
> >>> On Sun, Feb 14, 2010 at 1:36 AM, Zoka <ztomi...@gmail.com> wrote:
>
> >>>> Hi all,
>
> >>>> The Eclipse based V8 debugger   (http://code.google.com/p/

> >>>> chromedevtools/ <http://code.google.com/p/chromedevtools/>)  seems to

> Server running athttp://127.0.0.1:8000/


> [New Thread 0x7fffd2660910 (LWP 5571)]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000005596b8 in
> v8::internal::Runtime_GetScopeCount(v8::internal::Arguments) ()
> (gdb) where
> #0  0x00000000005596b8 in
> v8::internal::Runtime_GetScopeCount(v8::internal::Arguments) ()
> #1  0x00007fffd2ea622a in ?? ()
> #2  0x00007fffd1e2d109 in ?? ()
> #3  0x00007fffd2ea61c1 in ?? ()
> #4  0x00007fffffff9ae0 in ?? ()
> #5  0x00007fffffff9b28 in ?? ()
> #6  0x00007fffd2efdef4 in ?? ()
> #7  0x0000000000000000 in ?? ()
> (gdb)


On OSX I get different stack trace when breakpoint is hit:

0 0x9319ee42 in __kill ()
#1 0x9319ee34 in kill$UNIX2003 ()
#2 0x9321123a in raise ()
#3 0x9321d679 in abort ()
#4 0x932123db in __assert_rtn ()
#5 0x0001cc50 in node::ObjectWrap::Unwrap<node::Connection>
(handle={val_ = 0xbfffbde4}) at node_object_wrap.h:26
#6 0x0001bdf9 in node::Connection::ReadyStateGetter
(property={<v8::Handle<v8::String>> = {val_ = 0x8065d0}, <No data
fields>}, info=@0xbfffbdcc) at ../src/node_net.cc:132
#7 0x001716e0 in v8::internal::Object::GetPropertyWithCallback
(this=0x778d35, receiver=0x778d35, structure=0x5afd15, name=0x5bf751,
holder=0x778d35) at /Users/Zoka/node/node/deps/v8/src/objects.cc:173
#8 0x001ad4d0 in DebugLookupResultValue (receiver=0x778d35,
name=0x5bf751, result=0xbfffbec4, caught_exception=0xbfffbebf) at /
Users/Zoka/node/node/deps/v8/src/runtime.cc:6209
#9 0x001b747d in Runtime_DebugGetPropertyDetails
(args={<v8::internal::Embedded> = {<No data fields>}, length_ = 2,
arguments_ = 0xbfffbf7c}) at /Users/Zoka/node/node/deps/v8/src/
runtime.cc:6305
#10 0x005da36e in ?? ()
#11 0x0310b3bc in ?? ()
#12 0x0310fce6 in ?? ()
#13 0x005db2bf in ?? ()
#14 0x007ec146 in ?? ()
#15 0x03117672 in ?? ()
#16 0x0311e7b5 in ?? ()
#17 0x005db2bf in ?? ()
#18 0x0310d142 in ?? ()
#19 0x0310b750 in ?? ()
#20 0x03107a27 in ?? ()
#21 0x031135fb in ?? ()
#22 0x03107a59 in ?? ()
#23 0x03107826 in ?? ()
#24 0x03106d8e in ?? ()
#25 0x031052a1 in ?? ()
#26 0x007af361 in ?? ()
#27 0x005e8839 in ?? ()
#28 0x005da882 in ?? ()
#29 0x0007c438 in Invoke (construct=false, func={location_ =
0x8065b8}, receiver={location_ = 0x8065b0}, argc=1, args=0xbfffc3ec,
has_pending_exception=0xbfffc32b) at /Users/Zoka/node/node/deps/v8/src/
execution.cc:97
#30 0x0007c8e6 in v8::internal::Execution::Call (func={location_ =
0x8065b8}, receiver={location_ = 0x8065b0}, argc=1, args=0xbfffc3ec,
pending_exception=0xbfffc32b) at /Users/Zoka/node/node/deps/v8/src/
execution.cc:124
#31 0x00046c12 in v8::Function::Call (this=0x8065b8, recv={val_ =
0x8065b0}, argc=1, argv=0xbfffc3ec) at /Users/Zoka/node/node/deps/v8/
src/api.cc:2426
#32 0x00075411 in v8::internal::Debugger::NotifyMessageHandler
(event=v8::Break, exec_state={location_ = 0x8065a0},
event_data={location_ = 0x80657c}, auto_continue=false) at /Users/Zoka/
node/node/deps/v8/src/debug.cc:2270
#33 0x00075850 in v8::internal::Debugger::ProcessDebugEvent
(event=v8::Break, event_data={location_ = 0x80657c},
auto_continue=false) at /Users/Zoka/node/node/deps/v8/src/debug.cc:
2106
#34 0x00076716 in v8::internal::Debugger::OnDebugBreak
(break_points_hit={location_ = 0x8064f8}, auto_continue=false) at /
Users/Zoka/node/node/deps/v8/src/debug.cc:1936
#35 0x00078993 in v8::internal::Debug::Break
(args={<v8::internal::Embedded> = {<No data fields>}, length_ = 0,
arguments_ = 0xbfffc834}) at /Users/Zoka/node/node/deps/v8/src/
debug.cc:873
#36 0x005dca29 in ?? ()
#37 0x007f3f35 in ?? ()
#38 0x007e99df in ?? ()
#39 0x005e8839 in ?? ()
#40 0x005da882 in ?? ()
#41 0x0007c438 in Invoke (construct=false, func={location_ =
0x8064d0}, receiver={location_ = 0x8064c0}, argc=0, args=0xbfffcab0,
has_pending_exception=0xbfffc9bb) at /Users/Zoka/node/node/deps/v8/src/
execution.cc:97
#42 0x0007c8e6 in v8::internal::Execution::Call (func={location_ =
0x8064d0}, receiver={location_ = 0x8064c0}, argc=0, args=0xbfffcab0,
pending_exception=0xbfffc9bb) at /Users/Zoka/node/node/deps/v8/src/
execution.cc:124
#43 0x00046c12 in v8::Function::Call (this=0x8064d0, recv={val_ =
0x8064c0}, argc=0, argv=0xbfffcab0) at /Users/Zoka/node/node/deps/v8/
src/api.cc:2426
#44 0x00012adc in ReallyEmit (self={val_ = 0x8064c0}, event={val_ =
0xbfffcc98}, argc=0, argv=0xbfffcab0) at ../src/node_events.cc:65
#45 0x00012dca in node::EventEmitter::Emit (args=@0xbfffcbb8) at ../
src/node_events.cc:93
#46 0x00064179 in HandleApiCallHelper<false>
(args={<v8::internal::Arguments> = {<v8::internal::Embedded> = {<No
data fields>}, length_ = 3, arguments_ = 0xbfffcc9c}, <No data
fields>}) at /Users/Zoka/node/node/deps/v8/src/builtins.cc:451
#47 0x00064225 in Builtin_Impl_HandleApiCall
(args={<v8::internal::Arguments> = {<v8::internal::Embedded> = {<No
data fields>}, length_ = 3, arguments_ = 0xbfffcc9c}, <No data
fields>}) at /Users/Zoka/node/node/deps/v8/src/builtins.cc:468
#48 0x00064244 in Builtin_HandleApiCall
(args={<v8::internal::Arguments> = {<v8::internal::Embedded> = {<No
data fields>}, length_ = 3, arguments_ = 0xbfffcc9c}, <No data
fields>}) at /Users/Zoka/node/node/deps/v8/src/builtins.cc:467
#49 0x005da36e in ?? ()
#50 0x00798867 in ?? ()
#51 0x005e8839 in ?? ()
#52 0x005da882 in ?? ()
#53 0x0007c438 in Invoke (construct=false, func={location_ =
0x8064b0}, receiver={location_ = 0x54c5a4}, argc=0, args=0x0,
has_pending_exception=0xbfffcdfb) at /Users/Zoka/node/node/deps/v8/src/
execution.cc:97
#54 0x0007c8e6 in v8::internal::Execution::Call (func={location_ =
0x8064b0}, receiver={location_ = 0x54c5a4}, argc=0, args=0x0,
pending_exception=0xbfffcdfb) at /Users/Zoka/node/node/deps/v8/src/
execution.cc:124
#55 0x00046c12 in v8::Function::Call (this=0x8064b0, recv={val_ =
0x54c5a4}, argc=0, argv=0x0) at /Users/Zoka/node/node/deps/v8/src/
api.cc:2426
#56 0x00012adc in ReallyEmit (self={val_ = 0x54c5a4}, event={val_ =
0x54c630}, argc=0, argv=0x0) at ../src/node_events.cc:65
#57 0x00012c21 in node::EventEmitter::Emit (this=0x6009a0, event={val_
= 0x54c630}, argc=0, argv=0x0) at ../src/node_events.cc:100
#58 0x00016a15 in node::HTTPConnection::on_message_complete
(parser=0x600a60) at ../src/node_http.cc:180
#59 0x000309da in message_complete_callback (parser=0x600a60) at ../
deps/http_parser/http_parser.c:97
#60 0x0002fe6f in http_parser_execute (parser=0x600a60,
data=0xbfffd198 "HTTP/1.1 200 OK\r\ndate: Sat, 13 Feb 2010 21:32:09 GMT
\r\nserver: hi\r\nstatus: 200 OK\r\nx-served-from: b029\r\nx-runtime:
0.04965\r\ncontent-type: application/json; charset=utf-8\r\nx-served-
by: c086.twitter.com\r"..., len=1118) at ../deps/http_parser/
http_parser.c:1318
#61 0x00016880 in node::HTTPConnection::OnReceive (this=0x6009a0,
buf=0xbfffd198, len=1118) at ../src/node_http.cc:112
#62 0x0001c651 in node::Connection::on_read (s=0x6009bc,
buf=0xbfffd198, len=1118) at node_net.h:126
#63 0x0002b837 in stream_recv__data (stream=0x6009bc) at ../deps/evcom/
evcom.c:562
#64 0x0002c829 in stream_event (w=0x6009cc, revents=1) at ../deps/
evcom/evcom.c:1033
#65 0x00023c95 in ev_invoke_pending () at ../deps/libev/ev.c:1997
#66 0x00024409 in ev_loop (flags=0) at ../deps/libev/ev.c:2359
#67 0x00002d6d in Loop (args=@0xbffff338) at ../src/node.cc:408
#68 0x00064179 in HandleApiCallHelper<false>
(args={<v8::internal::Arguments> = {<v8::internal::Embedded> = {<No
data fields>}, length_ = 2, arguments_ = 0xbffff40c}, <No data
fields>}) at /Users/Zoka/node/node/deps/v8/src/builtins.cc:451
#69 0x00064225 in Builtin_Impl_HandleApiCall
(args={<v8::internal::Arguments> = {<v8::internal::Embedded> = {<No
data fields>}, length_ = 2, arguments_ = 0xbffff40c}, <No data
fields>}) at /Users/Zoka/node/node/deps/v8/src/builtins.cc:468
#70 0x00064244 in Builtin_HandleApiCall
(args={<v8::internal::Arguments> = {<v8::internal::Embedded> = {<No
data fields>}, length_ = 2, arguments_ = 0xbffff40c}, <No data
fields>}) at /Users/Zoka/node/node/deps/v8/src/builtins.cc:467
#71 0x005da36e in ?? ()
#72 0x005fbb92 in ?? ()
#73 0x005e8839 in ?? ()
#74 0x005da882 in ?? ()
#75 0x0007c438 in Invoke (construct=false, func={location_ =
0x8063e0}, receiver={location_ = 0x805c28}, argc=1, args=0xbffff608,
has_pending_exception=0xbffff58b) at /Users/Zoka/node/node/deps/v8/src/
execution.cc:97
#76 0x0007c8e6 in v8::internal::Execution::Call (func={location_ =
0x8063e0}, receiver={location_ = 0x805c28}, argc=1, args=0xbffff608,
pending_exception=0xbffff58b) at /Users/Zoka/node/node/deps/v8/src/
execution.cc:124
#77 0x00046c12 in v8::Function::Call (this=0x8063e0, recv={val_ =
0x805c28}, argc=1, argv=0xbffff608) at /Users/Zoka/node/node/deps/v8/
src/api.cc:2426
#78 0x000074b9 in Load (argc=3, argv=0xbffff968) at ../src/node.cc:
1058
#79 0x00007859 in main (argc=3, argv=0xbffff968) at ../src/node.cc:
1187
(gdb)


Message has been deleted

Zoka

unread,
Feb 14, 2010, 9:17:45 PM2/14/10
to nodejs
Hi,
Here is the minimal test case that can reproduce the crash when
breakpoint is reached:

var sys=require('sys');
var count = 0;

function timer_tick() {
count = count+1;
sys.puts("Tick count : " + count);
setTimeout(timer_tick, 1000);

}

timer_tick();

Setting breakpoint anywhere in timer_tick body will cause crash in
ObjectWrap::Unwrap in Timer::RepatGetter accessor method. Initially I
suspected threading issue,
however all relevant processing is done in main V8 thread.

Handle<Value>
Timer::RepeatGetter (Local<String> property, const AccessorInfo& info)
{
HandleScope scope;
Timer *timer = ObjectWrap::Unwrap<Timer>(info.This()); // -------
Crash point

assert(timer);
assert (property == repeat_symbol);

Local<Integer> v = Integer::New(timer->watcher_.repeat);

return scope.Close(v);

}

Unwrap method in this function fails because InternalFieldCount() is
zero, despite being set to 1 by constructor_template.
The RepeatGetter method is never used in normal operation, it is
called only after breakpoint is hit because debugger wants to examine
the
Timer instance repeat property. I guess that is why it was not noticed
before.

Other invocation of unwrap is in Timer::Start and this one is being
called on every setTimeout(), but with different parameter:

Handle<Value>
Timer::Start (const Arguments& args)
{
Timer *timer = ObjectWrap::Unwrap<Timer>(args.Holder());
...

It is quite mind boggling that unwrapping args.Holder() and
info.This() is supposed to give the very same Timer instance
pointer :-))

Reply all
Reply to author
Forward
0 new messages