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.

Sign up for GitHub

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

Jump to bottom

Segmentation Fault caused by uncatchable exception #344

Open
aidupl opened this issue Jan 8, 2020 · 5 comments · May be fixed by #478
Open

Segmentation Fault caused by uncatchable exception #344

aidupl opened this issue Jan 8, 2020 · 5 comments · May be fixed by #478

Comments

@aidupl
Copy link

aidupl commented Jan 8, 2020

While testing some Lua scripts using NLua I've encountered a strange behavior, possibly related to some bug with runtime stack. Here is a minimal example of the bug reproduction: LuaTest.zip

How the code works:
The Lua script is being loaded into a new Lua state and executed.
The pcall functions call TestClass method exceptionMethod which throws an exception. The exception should be caught by the pcall and store the exception in err and errMsg variables.
When executing the code on Windows 10 everything works as expected. I can see the output of WriteLine:

False : NLua.Exceptions.LuaScriptException: A .NET exception occured in user-code
False : NLua.Exceptions.LuaScriptException: A .NET exception occured in user-code

However the same code executed on Ubuntu 18.04 ends with a "Segmentation fault (core dumped)" and no output.
When running the app through the debugger on Ubuntu i can see:

Exception thrown: 'System.Exception' in SampleApp.dll
Exception thrown: 'System.Exception' in Unknown Module.
The program '[31625] SampleApp.dll' has exited with code 0 (0x0).

I have tested the code on .NET Core versions 3.0.1 and 3.1 producing the same results on both Windows 10 (works as expected) and Ubuntu 18.04 (results in segmentation fault).

I expect that throwing the exception (maybe) breaks the stack but I don't know how to test this further or fix it. Could it be a bug in the runtime implementation for linux?
@viniciusjarina
Copy link
Member

HI @aidupl would mind to write the test as a NUnit test and send a PR instead a zip file? Thank you very much.

@aidupl
Copy link
Author

aidupl commented Jan 9, 2020

Hello @viniciusjarina I was able to write two tests that cause a crash with a different outcome. Both caused by throwing multiple exceptions.

@aidupl aidupl mentioned this issue Jan 9, 2020
Closed
@aidupl
Copy link
Author

aidupl commented Jan 15, 2020

I have also created an issue regarding this problem for the dotnet runtime and received an
answer. Maybe this could help you track what is going on?

@viniciusjarina
Copy link
Member

Thank you @aidupl I still didn't have time to investigate the issue. Is this also happening using WSL ?

viniciusjarina added a commit that referenced this issue Jan 15, 2020
@viniciusjarina
Move call to lua_error to the same level of the delegate callback
9c77a9f 
* Lua.Error() will call setjmp and this can cause a crash with CLR on Linux, it seems that calling the setjmp longjmp twice will crash on *nix systems.
This should make this issue work a bit better: #344
@viniciusjarina viniciusjarina mentioned this issue Jan 15, 2020
Merged
@viniciusjarina
Copy link
Member

@aidupl I don't think would be possible to workaround this issue without change the Lua source code.

What I suggest is you to wrap your .NET calls into a single lua method and then use pcall to call it.

Like I did here https://github.com/NLua/NLua/pull/347/files#diff-8aa37412f4b48b161b9e772ef2a6e850R2751

Hopefully this patch #347 will help Mono/CLR to behave a bit better calling lua_error.

viniciusjarina added a commit that referenced this issue Jan 18, 2020
@viniciusjarina
Move call to lua_error to the same level of the delegate callback
ceac1a5 
* Lua.Error() will call setjmp and this can cause a crash with CLR on Linux, it seems that calling the setjmp longjmp twice will crash on *nix systems.
This should make this issue work a bit better: #344
Popax21 added a commit to Popax21/NLua that referenced this issue Feb 5, 2023
@Popax21
Wrap C functions to throw errors in Lua functions
e5b81a2 
This change makes all C functions not throw their Lua errors directly,
and instead makes them return it for a Lua wrapper to pick up and raise.
By doing this, the issue of longjmp translation is bypassed/fixed on
non-Windows platforms, as the errors are thrown and caught inside native
Lua runtime code.

Fixes NLua#344
@Popax21 Popax21 linked a pull request Feb 5, 2023 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Wrap C functions to throw errors in wrapper Lua functions Popax21/NLua
2 participants
@viniciusjarina @aidupl