Using --hydrogen_track_positions flag triggers crash in debug mode

[Gabriel Southern]

I wanted to try IRHydra2 (http://mrale.ph/irhydra/2/) with the Octane benchmarks.  When I use the x64.debug version of d8 with the flags listed for IRHydra2 and run the Octane benchmarks I get a crash in the interpreter.

I tried to narrow down the problem, and it looks like --hydrogen_track_positions is the flag that gives the problem.  The stack trace that I get when d8 crashes is:

#

# Fatal error in ../src/assembler.cc, line 1551

# CHECK(pos >= 0) failed

#

==== C stack trace ===============================

 1: V8_Fatal

 2: v8::internal::PositionsRecorder::RecordPosition(int)

 3: v8::internal::LCodeGen::RecordAndWritePosition(int)

 4: v8::internal::LCodeGenBase::GenerateBody()

 5: v8::internal::LCodeGen::GenerateCode()

 6: v8::internal::LChunk::Codegen()

 7: v8::internal::OptimizedCompileJob::GenerateCode()

 8: v8::internal::Compiler::GetConcurrentlyOptimizedCode(v8::internal::OptimizedCompileJob*)

 9: v8::internal::OptimizingCompilerThread::InstallOptimizedFunctions()

10: ??

11: v8::internal::Runtime_TryInstallOptimizedCode(int, v8::internal::Object**, v8::internal::Isolate*)

12: ??

Looking in gdb I think the problem is that the check DCHECK(pos >= 0) in PositionsRecorder::RecordPosition(int) fails in debug mode because pos is -842150428.  Running in release mode the interpreter doesn't crash, probably since the check is not run, but I'm wondering if the output can be trusted to be correct.

I noticed an issue related to the --hydrogen_track_positions flag had been opened in Feb, 2014: https://code.google.com/p/v8/issues/detail?id=3184

I also have experienced this problem when compiling either the master or the bleeding_edge branch (from the git repo).

I'm using Ubuntu 12.04 with Linux 3.5 and gcc 4.7.3.  I've tried with both x64 and ia32 and seen the crash in both cases.  Any suggestions for debugging the problem are appreciated.  I'm wondering if it's something specific to my system, or a bug in V8.  And whether it really matters for using IRHydra2 or not.

-Gabriel

[Vyacheslav Egorov]

Hi Gabriel,

I took a quick look into this and it's actually an issue in my code: we are trying to lookup SharedFunctionInfo by inlining_id in the list that is actually indexed by something else entirely (unique id of inlined function). So we if we inline the same function twice we end up reading out of bounds (if you run with --enable-slow-asserts you will get bounds check error). I will fix this.

Good news: this does *not* affect IRHydra, because IRHydra does not rely on "linearized" source positions encoded in the code, it uses whatever is encoded in the hydrogen.cfg file, and those are correct.

Vyacheslav Egorov

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sven Panne]

On Wed, Oct 15, 2014 at 3:44 AM, Vyacheslav Egorov <veg...@chromium.org> wrote:

[...] I will fix this. [...]

It might be good to check that IRHydra still likes v8's output. A few weeks ago I've threaded some information regarding the deoptimization reason through our deoptimization machinery, so without any tools you'll have a better idea what's going on and where. The only thing you need to do is add "--trace-deopt --code-comments", and you get e.g.

   ...

   [deoptimizing (DEOPT eager): begin 0x367a3031 astar.search (opt #6) @53, FP to SP delta: 140]

               ;;; deoptimize at <0:4675> bounds-check: out of bounds

   ...

It's still only semi-user-friendly, but at least it tells you that at 4675 characters from the start of your sources, an out-of-bounds access occurred. Having to specify --code-comments is still a hack, but we know how to fix this when we have time (basically push the reason and pop it in the deoptimization handler).

[Vyacheslav Egorov]

> It might be good to check that IRHydra still likes v8's output

I do use it regularly so I usually notice when it breaks :) The only part of deoptimization output I rely on is the first line which contains all necessary information to map deopt into the source (optimization-id & bailout-id).

I was extremely excited to see your CL land btw. Really looking forward for more comprehensive deoptimization messages!

Just checked with a bleeding edge V8 and everything still works. 

 

PS I also uploaded a fix for the crash in question: https://codereview.chromium.org/653993005/

Vyacheslav Egorov

--

[Gabriel Southern]

Thanks for the explanation of the bug and for patching the code.

-Gabriel

You received this message because you are subscribed to a topic in the Google Groups "v8-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-users/CDr8QOxH_00/unsubscribe.
To unsubscribe from this group and all its topics, send an email to v8-users+u...@googlegroups.com.