Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZiplineScoped initial plumbing #773

Merged
merged 4 commits into from
Dec 16, 2022
Merged

Conversation

swankjesse
Copy link
Contributor

No description provided.

Previously it was a member of OutboundCallHandler, but this
caused OutboundHandler to transitively reach the ZiplineService,
which broke leak detection.
@swankjesse
Copy link
Contributor Author

I think this shook out a bug in our JS leak detection. I’ve introduced a reference cycle that involves the object we’re tracking (the outbound service) and its scope, and I suspect it’s unsafe to run code in this situation.

To avoid the cycle I’d need to limit what the scope knows. That might be okay.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007ff71fa3b759, pid=15812, tid=15814
#
# JRE version: OpenJDK Runtime Environment Zulu11.60+19-CA (11.0.17+8) (build 11.0.17+8-LTS)
# Java VM: OpenJDK 64-Bit Server VM Zulu11.60+19-CA (11.0.17+8-LTS, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C  [quickjs2619729428427931323.tmp+0x3b759]  __JS_FreeValueRT+0xa9
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/runner/work/zipline/zipline/zipline/core.15812)
#
# An error report file with more information is saved as:
# /home/runner/work/zipline/zipline/zipline/hs_err_pid15812.log
#
# If you would like to submit a bug report, please visit:
#   http://www.azul.com/support/
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
app.cash.zipline.LeakedServicesTest[jvm] > jsLeaksService[jvm] SKIPPED

if (closed) return
closed = true

val servicesCopy = services.toTypedArray() // Because ZiplineService.close() mutates the set.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about calling services.clear() here so that the calls to remove() are a no-op rather than wastefully doing a bunch of set ops?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oooooh I like. Done.

Comment on lines +22 to +23
* Do not extend this in your [ZiplineService] interfaces; it should only be implemented by concrete
* implementation classes.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can the compiler validate this? At least on dealing with calls to take walk its interface hierarchy and validate none do this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolutely. On the list.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@swankjesse swankjesse merged commit d69f694 into trunk Dec 16, 2022
@swankjesse swankjesse deleted the jwilson.1216.ZiplineScoped branch December 16, 2022 22:32
@swankjesse swankjesse mentioned this pull request Dec 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants