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

Random SIGILL on macOS #242

Closed
LoganDark opened this issue Aug 31, 2019 · 7 comments
Closed

Random SIGILL on macOS #242

LoganDark opened this issue Aug 31, 2019 · 7 comments
Labels

Comments

@LoganDark
Copy link

LoganDark commented Aug 31, 2019

As discussed in #241 my profiler causes random SIGILLs in Minecraft for some reason. I'm not sure why, it just happens.

I'm using a build provided by @apangin of the latest master commit, which supposedly solved a macOS issue. Not this one it seems...

The profiler is running in IntelliJ IDEA 2019.2 Ultimate on macOS 10.14.5.

No crash report, log, etc. is ever generated. Output simply stops with this message:

Process finished with exit code 132 (interrupted by signal 4: SIGILL)
@apangin
Copy link
Collaborator

apangin commented Sep 1, 2019

I reproduced the bug. Looks like the same problem as #219. The previous fix is incomplete.
Will investigate this further...

@apangin apangin added the bug label Sep 1, 2019
@LoganDark
Copy link
Author

LoganDark commented Sep 1, 2019

That's interesting because this is JDK 8... even the IDE itself is running on 8 (not 10 like usual).

@apangin
Copy link
Collaborator

apangin commented Sep 1, 2019

I think I found the problem.
Profiler was using pthread_mach_thread_np function to get current thread ID inside signal handler, however, the function is not async signal safe.

Replaced it with mach_thread_self syscall.

Please check the updated version -
async-profiler-1.6-ea-macos-x64.tar.gz

@LoganDark
Copy link
Author

@apangin Have any idea when exactly it would crash in that case, or was it just undefined behavior or some kind of race condition?

@apangin
Copy link
Collaborator

apangin commented Sep 1, 2019

A race condition.
I don't have a reliable way to reproduce the bug, but chances are higher when profiling an application with many active threads, using small profiling interval and "threads" option.

I haven't seen crashes on my side after the fix.

An interesting fact is that JVM also uses pthread_mach_thread_np to get current thread ID, including the crash reporting code. Actually JVM catches the error, but when trying to create a crash report, it also calls the problematic function and then recursively fails.

@LoganDark
Copy link
Author

Absolutely 0 crashes! I've just been messing around normally, running some very intensive tasks that involve threading (including incredibly multiplexed pathing algorithms) with no issue. Thank you!

Your profiler also no longer randomly crashes and freezes (without termination) when collecting data :>

@LoganDark
Copy link
Author

Thank you so much for this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants