Bug 188491 – Break reference cycle in ErrorEvent by using JSValueInWrappedObject

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Yusuke Suzuki]

ErrorEvent should not hold error strongly

[Yusuke Suzuki]

Created attachment 346988 [details]
Patch

[Yusuke Suzuki]

Created attachment 346989 [details]
Patch

[Darin Adler]

Comment on attachment 346989 [details]
Patch

I don’t fully understand the implications of aerialiing an object that could be changed after its serialized. Or if we are doing the right thing when there are multiple worlds involved. But that’s not specific to this patch, which is applying a pattern we already follow elsewhere.

[Darin Adler]

Title of bug is not exactly right since it does need to hold the error “strongly” in the sense that its a reference that keeps the error object alive, just needs to do it in a way that is garbage collection compatible and doesn’t lead to reference cycles and storage leaks!

[Yusuke Suzuki]

Committed r234789: <https://trac.webkit.org/changeset/234789>

[Radar WebKit Bug Importer]

<rdar://problem/43210312>

[Truitt Savell]

Looks like this revision <https://trac.webkit.org/changeset/234789> 

has caused build failure on Windows release https://build.webkit.org/builders/Apple%20Win%20Release%20%28Build%29/builds/11156

error stdio:
https://build.webkit.org/builders/Apple%20Win%20Release%20%28Build%29/builds/11156/steps/compile-webkit/logs/stdio

[Darin Adler]

Seems highly unlikely this change directly caused that build failure; maybe due to adding a new unified source file? The failure is a link error about export of a symbol affecting units tests. We should get someone to dive deeper into it. A rollout would be OK but this seems really peculiar.