| Summary: | ScriptDebugServer wants sourceIDs that are non-zero because that's what HashMaps want, so JSC should placate it | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Filip Pizlo <fpizlo> | ||||||
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | ggaren | ||||||
| Priority: | P2 | Keywords: | InRadar | ||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Attachments: |
|
||||||||
|
Description
Filip Pizlo
2012-05-30 12:51:49 PDT
Created attachment 144900 [details]
the patch
Comment on attachment 144900 [details]
the patch
r=me
Comment on attachment 144900 [details]
the patch
Do we actually call SourceProvider::asID on a null pointer? Why?
(In reply to comment #3) > (From update of attachment 144900 [details]) > Do we actually call SourceProvider::asID on a null pointer? Why? Null SourceProvider means something like "I have an unnamed source provider". There are a few places in the code where we explicitly check for null SourceProviders, but the asID() method is called without such checks, and generally works OK except when it returns zero and that zero ends up in some HashMap in the bindings. On second thought, how do we ever end up with a NULL source provider? I would expect some operations, like toString, which don't check for NULL, to crash in that case. It seems like NULL might be a bug. Landed in http://trac.webkit.org/changeset/118960 Reopening because it would be better to check for null SourceProvider at the call site, rather than inside the function. Created attachment 144918 [details]
a better patch
Better fix landed in http://trac.webkit.org/changeset/118966 |