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

JVM crash on executing win_sparkle_did_find_update callback #1

Closed
1 task done
purejava opened this issue Dec 1, 2022 · 4 comments
Closed
1 task done

JVM crash on executing win_sparkle_did_find_update callback #1

purejava opened this issue Dec 1, 2022 · 4 comments
Labels
bug Something isn't working upstream

Comments

@purejava
Copy link
Owner

purejava commented Dec 1, 2022

Please agree to the following

Summary

JVM crashes on executing callback

What software is involved?

  • Operating System: Windows 11
  • winsparkle-java: 1.0.0

Steps to Reproduce

  1. Define a callback class
public class CB implements win_sparkle_did_find_update_callback_t {
  @Override
  public void apply() {
  }
}
  1. Set apply() method as the callback function to be executed
winsparkle_h.win_sparkle_set_did_find_update_callback(MemoryAllocator.ALLOCATE_CALLBACK_FOR(new CB()));
  1. Trigger the callback function via WinSparkle

Expected Behavior

Callback function executes

Actual Behavior

JVM crashes

Reproducibility

Always

Relevant Log Output

See below

Anything else?

A bug report has been submitted upstream at https://bugreport.java.com/bugreport/crash.jsp

@purejava purejava added the bug Something isn't working label Dec 1, 2022
@purejava
Copy link
Owner Author

purejava commented Dec 1, 2022

hs_err_pid3060.log

@purejava
Copy link
Owner Author

purejava commented Dec 2, 2022

Today Oracle assigned a bug ID to my bug report.

@purejava
Copy link
Owner Author

Oracle looked into the report and created an additional bug report, that describes the root cause for this issue and suggests a solution:

Root cause
The callback is eligible for garbage collection after the setter returns, since there are no strong references to it. It is possible (or likely) that the callback is freed before it is called, and the call will jump through a dangling pointer instead, which would likely cause a crash.

Solution
Replace the use of an implicit memory session with a shared session and allocate the memory for a callback (aka setting the pointer to a function that is executed as the callback) in the shared session.

@purejava
Copy link
Owner Author

Fixed by 66c49e1 and released with version 1.1.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working upstream
Projects
None yet
Development

No branches or pull requests

1 participant