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

Replace manual handle memory management with GC allocated space #2

Conversation

WojciechMazur
Copy link

Fixes the segmentation faults when clearing timer multiple times. There was no way to determine when Timer was already free. On some systems it was fine (MacOS) as the memory was not reused, on others (Ubuntu) it seems like retained memory was reallocated and overridden leading to segmentation fault in a call to uv_close

New approach makes sure that as long as we have handle to Timer/Poll the memory would never be retained and overridden. It also allows to skip reference counting to prevent GCing the callbacks.

…imer/Poll handles. Fixes use-after-free errors leading to segfaults
import internals.HandleUtils

@inline final class Timer private (private val ptr: Ptr[Byte]) extends AnyVal {
@inline final class Timer private (private val data: BlobArray) extends AnyVal {
Copy link
Author

Choose a reason for hiding this comment

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

Question:
Should we have a registry for active timers? It makes sense for the repeated timers running for the long time in the background. If user does not keep any handle to them, then they can be GCed at some point. How often due users use them in such way?
For safety reasons it might be best to keep them as long as the libUV might trigger the callback. Unfortunetlly we need to bridge 2 memory spaces - the SN space and libUV space.

Copy link
Owner

Choose a reason for hiding this comment

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

Perhaps @lolgab would know the answer?

Copy link
Owner

@sideeffffect sideeffffect left a comment

Choose a reason for hiding this comment

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

❤️

@sideeffffect sideeffffect merged commit 3afc321 into sideeffffect:scala-native-0.5.x Jun 17, 2024
1 check passed
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.

2 participants