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

SIGSEGV after ~254 times calling "callFrontendJs" / "callJs" when threads enabled and using "--gc:refc" #29

Closed
marcomq opened this issue Oct 18, 2021 · 5 comments

Comments

@marcomq
Copy link
Owner

marcomq commented Oct 18, 2021

Nimview applications consistently crash when using the desktop mode on linux after calling about 243 times "callFrontendJs". This only happens in Nimview 0.3.2, as the function previously had issues. This doesn't happen on windows.
There is a SIGSEGV: Illegal stroage access. (Attempt to read from nil?)
image

This happens in Nim 1.4 and Nim 1.6, on linux and on windows in release mode.

Workaround:
Either not using "callFrontendJs" or using --gc:orc --deepCopy:on as compile option.
Both seems to successfully fix the crashes.

@marcomq marcomq added the bug Something isn't working label Oct 18, 2021
@marcomq marcomq changed the title stability / gc issues stability / gc issues since Nimview 0.3.2 Oct 18, 2021
@marcomq marcomq changed the title stability / gc issues since Nimview 0.3.2 stability / gc issues after ~243 callFrontendJs Oct 23, 2021
@marcomq marcomq changed the title stability / gc issues after ~243 callFrontendJs stability / gc issues after ~243 times calling "callFrontendJs" Oct 23, 2021
@marcomq marcomq changed the title stability / gc issues after ~243 times calling "callFrontendJs" crash after ~243 times calling "callFrontendJs" Oct 23, 2021
@marcomq marcomq changed the title crash after ~243 times calling "callFrontendJs" SIGSEGV after ~243 times calling "callFrontendJs" Oct 23, 2021
@marcomq marcomq added wontfix This will not be worked on and removed bug Something isn't working labels Oct 25, 2021
@marcomq
Copy link
Owner Author

marcomq commented Oct 25, 2021

Only happens on linux and on windows with -d:release when default gc is used.
No issue anymore when compiling with threads:off, -d:useWebviewSingleThreaded or when using --gc:orc --deepCopy:on.

Edit:
I'm currently not working on this anymore as this seems to be hard to fix (for me).
This is most likely connected to the (old) Nim garbage collector and some unsafe calls to a global "var" from thread.

@marcomq marcomq removed the wontfix This will not be worked on label Oct 25, 2021
@marcomq marcomq changed the title SIGSEGV after ~243 times calling "callFrontendJs" SIGSEGV after ~254 times calling "callFrontendJs" Oct 25, 2021
@marcomq marcomq changed the title SIGSEGV after ~254 times calling "callFrontendJs" SIGSEGV after ~254 times calling "callFrontendJs" / "callJs" Nov 6, 2021
@marcomq
Copy link
Owner Author

marcomq commented Nov 8, 2021

Resolved it by refactoring globals and storage.
Will be resolved in 0.4.1

@marcomq marcomq closed this as completed Nov 8, 2021
@marcomq
Copy link
Owner Author

marcomq commented Nov 8, 2021

Only happens when threads are enabled and default gc is used. Workaround: use --gc:orc

@marcomq marcomq changed the title SIGSEGV after ~254 times calling "callFrontendJs" / "callJs" SIGSEGV after ~254 times calling "callFrontendJs" / "callJs" when threads enabled and using default GC Nov 8, 2021
@marcomq marcomq changed the title SIGSEGV after ~254 times calling "callFrontendJs" / "callJs" when threads enabled and using default GC SIGSEGV after ~254 times calling "callFrontendJs" / "callJs" when threads enabled and using "--gc:refc" Nov 8, 2021
@marcomq marcomq reopened this Nov 8, 2021
@marcomq
Copy link
Owner Author

marcomq commented Dec 1, 2021

Found some issue when using single-thread and httpserver mode. Fixed for current main branch.

@marcomq
Copy link
Owner Author

marcomq commented Dec 4, 2021

This is probably not fixable in any easy way.
I added a warning in "callJs" if threads are active and orc/arc is not the current gc/mm.

Closing this as there probably won't be any fix in future.

@marcomq marcomq closed this as completed Dec 4, 2021
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

No branches or pull requests

1 participant