Summary: | [Qt] QWebScriptWorld::world() may crash | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Yi Shen <max.hong.shen> | ||||||
Component: | WebKit Qt | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Minor | CC: | commit-queue, kling | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | PC | ||||||||
OS: | All | ||||||||
Attachments: |
|
Description
Yi Shen
2010-11-10 13:49:11 PST
Created attachment 73536 [details]
first try
Comment on attachment 73536 [details] first try View in context: https://bugs.webkit.org/attachment.cgi?id=73536&action=review > WebKit/qt/Api/qwebscriptworld.cpp:53 > + return d.data() ? d->world.get() : NULL; huh? how does world depend on data() ? Also we do not use NULL in C++ code. Created attachment 73593 [details]
second try
(In reply to comment #2) > (From update of attachment 73536 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=73536&action=review > > > WebKit/qt/Api/qwebscriptworld.cpp:53 > > + return d.data() ? d->world.get() : NULL; > > huh? how does world depend on data() ? Also we do not use NULL in C++ code. Thanks, you are right. I updated my patch, which returns 0 when the internal pointer to the shared data object is not null. Comment on attachment 73593 [details]
second try
This is a purely artificial problem since we always build with USE(JSC) and the V8 port will most likely require large changes to QWebScriptWorld anyway.
That said, I don't see any harm in adding this check. r=me
Comment on attachment 73593 [details] second try Clearing flags on attachment: 73593 Committed r71818: <http://trac.webkit.org/changeset/71818> All reviewed patches have been landed. Closing bug. |