Crash when debugging sunflower sample

[DartBot]

This issue was originally filed by podivilov@google.com

---

Open samples/sunflower/sunflower.html in Dartium. Open the developer tools, refresh to see the source files, and place a breakpoint in sunflower.dart on line 19 (PHI = ...). Then refresh.

[DartBot]

This comment was originally written by @mhausner

---

At what chagelist/revision of the Dart runtime is this happening? If this is before r5436, it most likely is due to optimized code. After this change, the debugger knows how to deoptimize functions when breakpoints are set in optimized code.

[DartBot]

This comment was originally written by podivilov@google.com

---

I still see the crash at r5464. Matthias, could you please take a look?

ASSERT(bpt->breakpoint_kind_ == PcDescriptors::kReturn) is failed:

#­0 *__GI_abort () at abort.c:128
#­1 0xf4a04011 in dart::DynamicAssertionHelper::Fail (this=0xff9ca7dc, format=0xf5c80eb1 "expected: %s") at dart/runtime/platform/assert.cc:41
#­2 0xf4919e01 in dart::Debugger::BreakpointCallback (this=0xf974e260) at dart/runtime/vm/debugger.cc:894
#­3 0xf4a1fed3 in DRT_HelperBreakpointDynamicHandler (arguments=<optimized out>, isolate=<optimized out>) at dart/runtime/vm/code_generator.cc:760
#­4 dart::DRT_BreakpointDynamicHandler (arguments=...) at dart/runtime/vm/code_generator.cc:756
#­5 0xee7000c2 in ?? ()
#­6 0xe8280334 in ?? ()
#­7 0xe828090d in ?? ()
#­8 0xe8280684 in ?? ()
#­9 0xe8280452 in ?? ()
#­10 0xe828006d in ?? ()
#­11 0xf490a988 in dart::DartEntry::InvokeStatic (function=..., arguments=..., optional_arguments_names=...) at dart/runtime/vm/dart_entry.cc:82
#­12 0xf48d0072 in dart::Dart_InvokeStatic (library_in=0xf97d90fc, class_name_in=0xf97d90f4, function_name_in=0xf97d90f0, number_of_arguments=0, arguments=0x0)
    at dart/runtime/vm/dart_api_impl.cc:2303
#­13 0xf324009d in WebCore::DartApplicationLoader::callEntryPoint ()

---

Set owner to @mhausner.

[DartBot]

This comment was originally written by @mhausner

---

Thank you Pavel. I will take a look today.

[DartBot]

This comment was originally written by podivilov@google.com

---

Please note that in debug mode it stops at "void drawFrame() {" for some reason. You need to hit F11 twice to observe the crash.

[DartBot]

This comment was originally written by @mhausner

---

I cannot reproduce the crash/assert mentioned above. I do however have an explanation why the breakpoint got set in the line "void drawFrame()".

The line info was off because the debugger indeed set the breakpoint at the wrong location. I have a fix for that that I'll send for review in a moment.

When I run Dartium in --single-process mode, I get a different assertion when the debugger breaks at line 19:

hit user breakpoint at file:///src/dartium/src/dart/samples/sunflower/Sunflower.dart:19 (Address 0x1b1807f8)

Fatal error in ../../src/objects-inl.h, line 1461

CHECK(index < GetInternalFieldCount() && index >= 0) failed

Abort trap

I am not sure this has anything to do with the debugger. If I run Dartium in regular mode (not single process) then everything works fine and I can single-step through the entire Sunflower code, including the closure that gets called when the slider value changes.

Please try again once the breakpoint location bug is fixed.

[DartBot]

This comment was originally written by @mhausner

---

Please try with a VM at r5501 or newer and let me know whether the crash can be reproduced.

[DartBot]

This comment was originally written by podivilov@google.com

---

At r5512 it still crashes.

1. set breakpoint at Sunflower.dart:31
2. reload
3. step over to drawFrame()
4. step into
5. crash

[DartBot]

This comment was originally written by @mhausner

---

Strange. I cannot reproduce the crash. The debugger correctly steps into drawFrame() and i can step through that function as well.

This is on the mac with the command line: ./xcodebuild/Debug/Chromium.app/Contents/MacOS/Chromium

If I start Dartium in single process mode, like so:

./xcodebuild/Debug/Chromium.app/Contents/MacOS/Chromium --single-process

I do see a crash even in item 3) in your list, stepping over line 31. The crash is in v8 code though. This is what the console output is:

Fatal error in ../../src/objects-inl.h, line 1461

CHECK(index < GetInternalFieldCount() && index >= 0) failed

What could I be doing wrong for me not to see the crash? Are you seeing this on Linux or on the Mac? I've had bugs before that only showed on one OS but not the other. In that case it was an uninitialized variable.

[DartBot]

This comment was originally written by lod...@google.com

---

For me, currently, on Linux, with the Dartium version that comes with the
current weekly download of DartEditor, it doesn't crash anymore, but breaks
at a wrong location in the file. Originally, it crashed with Aw Snap. There
must be something odd about the sunflower sample, because in other dart
applications the breakpoints seem to work fine.

[DartBot]

This comment was originally written by @mhausner

---

The inaccurate breakpoint locations are an known issue I have on my list of things to improve. In particular at the end of functions, the line number is off.

Sunflower is a neat small piece of Dart code that seems to contain a number of interesting corner cases for the debugger. I wouldn't call the Sunflower code odd. The debugger code is just not ready for prime time just yet.

[DartBot]

This comment was originally written by podivilov@google.com

---

Looks like this problem shows up on linux only. Latest linux build still crashes in sunflower's main() on "ASSERT(bpt->breakpoint_kind_ == PcDescriptors::kReturn)".

---

Added OpSys-Linux label.

[DartBot]

This comment was originally written by @mhausner

---

Ok, I figured it out. It's a use-after-free bug. Linux seems to poison the freed block but not MacOS. I'll have a fix out shortly.

[DartBot]

This comment was originally written by @mhausner

---

This should be fixed as of r5668.

---

Added Fixed label.