WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
22042
REGRESSION(
r38066
): ASSERTION FAILED: source in CodeBlock
https://bugs.webkit.org/show_bug.cgi?id=22042
Summary
REGRESSION(r38066): ASSERTION FAILED: source in CodeBlock
Matt Lilek
Reported
2008-11-02 13:02:11 PST
<
http://trac.webkit.org/changeset/38066
> caused an assertion failure on any page that has JavaScript. ASSERTION FAILED: source (/Users/matt/Code/WebKit/JavaScriptCore/VM/CodeBlock.h:264 JSC::CodeBlock::CodeBlock(JSC::ScopeNode*, JSC::CodeType, WTF::PassRefPtr<JSC::SourceProvider>, unsigned int))
Attachments
Fix
(1.41 KB, patch)
2008-11-02 13:04 PST
,
Matt Lilek
zwarich
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Matt Lilek
Comment 1
2008-11-02 13:04:20 PST
Created
attachment 24854
[details]
Fix My C++-foo isn't strong enough to know exactly why this was wrong, but this stops the ASSERT.
Cameron Zwarich (cpst)
Comment 2
2008-11-02 13:11:32 PST
Comment on
attachment 24854
[details]
Fix r=me if you change the parameters on the other two constructors in that file to match. This is a pretty bizarre thing. I wish I knew why it happened.
Matt Lilek
Comment 3
2008-11-02 13:15:48 PST
Committed revision 38068.
Geoffrey Garen
Comment 4
2008-11-03 10:23:56 PST
Doesn't this mean that all the name changes in
http://trac.webkit.org/changeset/38066
are invalid?
Cameron Zwarich (cpst)
Comment 5
2008-11-03 10:26:47 PST
The name changes are valid. The issue was that after the initializer , source(source) the PassRefPtr source was getting zeroed out, causing the assertion that source is nonzero to fail, where source is scoped to the parameter rather than the member variable. The assertion could also have been changed to ASSERT(this->source), and I might go back and do that.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug