Last Comment Bug 773108 - Crash [@ EmitAliasedVarOp]
: Crash [@ EmitAliasedVarOp]
Status: RESOLVED FIXED
[js:t]
: crash, regression, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 Mac OS X
: -- critical (vote)
: mozilla16
Assigned To: Luke Wagner [:luke]
: general
: Jason Orendorff [:jorendorff]
Mentors:
Depends on:
Blocks: jsfunfuzz 659577
  Show dependency treegraph
 
Reported: 2012-07-11 17:31 PDT by Gary Kwong [:gkw] [:nth10sd]
Modified: 2013-01-14 08:17 PST (History)
7 users (show)
choller: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
stack (9.33 KB, text/plain)
2012-07-11 17:31 PDT, Gary Kwong [:gkw] [:nth10sd]
no flags Details
fix and test (5.71 KB, patch)
2012-07-11 22:10 PDT, Luke Wagner [:luke]
dvander: review+
Details | Diff | Splinter Review

Description Gary Kwong [:gkw] [:nth10sd] 2012-07-11 17:31:59 PDT
Created attachment 641280 [details]
stack

Function("\
for each(l in[(let(c)([])\
for each(l in[]))(let(c)w for(u in[]))(let(u)w for(l in[]))(let(c)w for(u in[]))\
(let(u)w for each(l in[]))(let(c)w for(u in[]))(let(u)w for(l in[]))(let(c)w for(u in[]))\
(let(l)w for(l in[]))(let(u)w for(l in['']))(let(c)w for(u in[]))(let(u)w for(l in[]))\
(let(c)w for(l in[]))(let(l)w for(l in[]))(let(c)w for(l in[]))(let(u)w for(l in[]))\
(let(c)w for(l in[]))(let(u)w for each(l in[x]))(let(w,x)w for(u in[]))]){}\
")

crashes js opt shell on m-c changeset e4857e5dfb51 without any CLI argument on 10.6.

s-s just-in-case even though this seems to just be a null crash.

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   95788:4832054e4e42
user:        Luke Wagner
date:        Wed Apr 11 18:09:20 2012 -0700
summary:     Bug 659577 - emit ScopeCoordinate::hops (r=waldo)
Comment 1 Gary Kwong [:gkw] [:nth10sd] 2012-07-11 17:34:10 PDT
Julian, on 10.6 this asserts Valgrind (a binary from SVN circa June 22, 2012) too:

$ valgrind --dsymutil=yes ./js-opt-32-mozilla-central-darwin w10871-reduced.js 
==96146== Memcheck, a memory error detector
==96146== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==96146== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info
==96146== Command: ./js-opt-32-mozilla-central-darwin w10871-reduced.js
==96146== 
--96146-- run: /usr/bin/dsymutil "./js-opt-32-mozilla-central-darwin"

valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion 'VG_IS_32_ALIGNED(a_vex)' failed.
==96146==    at 0x3802DFA5: ???
==96146==    by 0x3802E168: ???
==96146==    by 0x38075687: ???
==96146==    by 0x38077517: ???
==96146==    by 0x3809C978: ???

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==96146==    at 0x8FE01030: _dyld_start (in /usr/lib/dyld)


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.
Comment 2 Luke Wagner [:luke] 2012-07-11 22:08:17 PDT
Gah, more ancient genexpr bugs exposed by my patch.  This will always fault at low-memory, so not s-s.
Comment 3 Luke Wagner [:luke] 2012-07-11 22:10:56 PDT
Created attachment 641356 [details] [diff] [review]
fix and test

The cause is pretty simple: pn_blockid is a 20 bit bitfield and we are adding an arbitrary value to it in AdjustBlockId without checking for overflow.

Bonus feature: the caller of transplant() no longer ignores errors.
Comment 4 Julian Seward [:jseward] 2012-07-12 00:41:23 PDT
(In reply to Gary Kwong [:gkw, :nth10sd] from comment #1)
> Julian, on 10.6 this asserts Valgrind (a binary from SVN circa June 22,
> 2012) too:
> valgrind: m_scheduler/scheduler.c:707 (do_pre_run_checks): Assertion
> 'VG_IS_32_ALIGNED(a_vex)' failed.

Unrelated .. this is a problem in V related to recently introduced AVX
instruction support.  Actually it's a bug in XCode when compiling V ..
As yet unresolved.
Comment 6 Ed Morley [:emorley] 2012-07-13 05:31:29 PDT
https://hg.mozilla.org/mozilla-central/rev/a2ec9847277d
Comment 7 Gary Kwong [:gkw] [:nth10sd] 2012-09-18 14:58:40 PDT
> Unrelated .. this is a problem in V related to recently introduced AVX
> instruction support.  Actually it's a bug in XCode when compiling V ..
> As yet unresolved.

Just want to note that I retested on Valgrind SVN r12999 and the Valgrind error did not show up, but I tested on 10.7 and no longer have a 10.6 machine.
Comment 8 Christian Holler (:decoder) 2013-01-14 08:17:09 PST
A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/testBug773108.js.

Note You need to log in before you can comment on or make changes to this bug.