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

segfault when linking to unwind library #4675

Closed
lemmel opened this issue Feb 13, 2018 · 6 comments
Closed

segfault when linking to unwind library #4675

lemmel opened this issue Feb 13, 2018 · 6 comments
Assignees

Comments

@lemmel
Copy link

lemmel commented Feb 13, 2018

When building a binary linked against the libwunwind, and when there is an exception inside ChakraCore, there is a segfault.

the problem

When using valgrind, I get:

==6096== Syscall param msync(start) points to uninitialised byte(s)
==6096==    at 0x690355B: msync (msync.c:25)
==6096==    by 0x4E3CFC3: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==6096==    by 0x4E40D20: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==6096==    by 0x4E4101E: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==6096==    by 0x4E41568: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==6096==    by 0x4E3DAC0: _ULx86_64_step (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==6096==    by 0x4E3C6D8: _Unwind_RaiseException (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==6096==    by 0x5AF5C26: __cxa_throw (in /home/XXX/.root/Applications/ChakraCore/out/Release/libChakraCore.so)
==6096==    by 0x5812BB3: Js::JavascriptExceptionOperators::DoThrow(Js::JavascriptExceptionObject*, Js::ScriptContext*) (in /home/XXX/.root/Applications/ChakraCore/out/Release/libChakraCore.so)
==6096==    by 0x581398F: Js::JavascriptExceptionOperators::ThrowExceptionObjectInternal(Js::JavascriptExceptionObject*, Js::ScriptContext*, bool, bool, void*, bool) (in /home/XXX/.root/Applications/ChakraCore/out/Release/libChakraCore.so)
==6096==    by 0x58130BA: Js::JavascriptExceptionOperators::ThrowExceptionObject(Js::JavascriptExceptionObject*, Js::ScriptContext*, bool, void*, bool) (in /home/XXX/.root/Applications/ChakraCore/out/Release/libChakraCore.so)
==6096==    by 0x5813074: Js::JavascriptExceptionOperators::Throw(void*, Js::ScriptContext*) (in /home/XXX/.root/Applications/ChakraCore/out/Release/libChakraCore.so)
==6096==  Address 0x1ffefff000 is on thread 1's stack
==6096==  in frame #6, created by _Unwind_RaiseException (???:)

==6096== 
==6096== Invalid read of size 8
==6096==    at 0x4E3CC14: _Ux86_64_setcontext (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==6096==    by 0x57A438E: Js::InterpreterStackFrame::InterpreterHelper(Js::ScriptFunction*, Js::ArgumentReader, void*, void*, Js::InterpreterStackFrame::AsmJsReturnStruct*) (in /home/XXX/.root/Applications/ChakraCore/out/Release/libChakraCore.so)
==6096==    by 0x57A3FBD: Js::InterpreterStackFrame::InterpreterThunk(Js::JavascriptCallStackLayout*) (in /home/XXX/.root/Applications/ChakraCore/out/Release/libChakraCore.so)
==6096==    by 0x4190FA1: ???
==6096==    by 0x5A063FD: amd64_CallFunction (in /home/melidrissi/.root/Applications/ChakraCore/out/Release/libChakraCore.so)
==6096==    by 0x58C599A: Js::JavascriptFunction::CallRootFunction(Js::Arguments, Js::ScriptContext*, bool) (in /home/XXX/.root/Applications/ChakraCore/out/Release/libChakraCore.so)
==6096==    by 0x543936B: RunScriptCore(void*, unsigned char const*, unsigned long, LoadScriptFlag, unsigned long, char16_t const*, bool, _JsParseScriptAttributes, bool, void**) (in /home/XXX/.root/Applications/ChakraCore/out/Release/libChakraCore.so)
==6096==    by 0x543CB3C: JsRun (in /home/XXX/.root/Applications/ChakraCore/out/Release/libChakraCore.so)
==6096==    by 0x108CD2: main (toto.cpp:53)
==6096==  Address 0x1ffeffed88 is on thread 1's stack
==6096==  2760 bytes below stack pointer

(full valgrind's log: vagrind_log.txt)

an idea/clue

When I look for unwind symbol in ChakraCore :

readelf -sW libChakraCore.so | grep _Unwind
    43: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_GetIPInfo@GCC_4.2.0 (10)
    47: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_Resume_or_Rethrow@GCC_3.3 (11)
    82: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_GetDataRelBase@GCC_3.0 (4)
   104: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_GetRegionStart@GCC_3.0 (4)
   134: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_SetGR@GCC_3.0 (4)
   165: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_GetTextRelBase@GCC_3.0 (4)
   219: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_Resume@GCC_3.0 (4)
   301: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_DeleteException@GCC_3.0 (4)
   354: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_RaiseException@GCC_3.0 (4)
   430: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_GetLanguageSpecificData@GCC_3.0 (4)
   445: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_SetIP@GCC_3.0 (4)
  3261: 0000000000882b60    59 FUNC    LOCAL  DEFAULT   11 _ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception
  3267: 0000000000883020    81 FUNC    LOCAL  DEFAULT   11 _ZL21base_of_encoded_valuehP15_Unwind_Context.part.3
  3268: 0000000000883080   241 FUNC    LOCAL  DEFAULT   11 _ZL17parse_lsda_headerP15_Unwind_ContextPKhP16lsda_header_info
 45291: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_GetIPInfo@@GCC_4.2.0
 45295: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_Resume_or_Rethrow@@GCC_3.3
 45330: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_GetDataRelBase@@GCC_3.0
 45352: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_GetRegionStart@@GCC_3.0
 45382: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_SetGR@@GCC_3.0
 45413: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_GetTextRelBase@@GCC_3.0
 45467: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_Resume@@GCC_3.0
 45549: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_DeleteException@@GCC_3.0
 45602: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_RaiseException@@GCC_3.0
 45677: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_GetLanguageSpecificData@@GCC_3.0
 45692: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _Unwind_SetIP@@GCC_3.0

There are marked as Undefined, and I read here on a similary ticket that it should not.

question

Can you tell me what I'm doing wrong ? This topic is a bit technical for me.

example code

starting with official linux sample
and replacing:

 const char* script = "(()=>{return \'Hello World!\';})()" ;

with

const char* script = "b";

in order to generate an exception.
My binary is build:

gcc -g -I/home/XXX/.root/Applications/ChakraCore/lib/Jsrt/ -L/home/XXX/.root/Applications/ChakraCore/out/Release  -lunwind -lunwind-x86_64  -lChakraCore -pthread -lm -ldl -licuuc toto.cpp

hardware/software

I'm under linux, using ChakraCore (git log) : commit 3f76911 (HEAD -> master, origin/master, origin/HEAD)

@obastemur
Copy link
Collaborator

@lemmel I'm assuming that you have a solution that depends on libunwind?

@lemmel
Copy link
Author

lemmel commented Feb 13, 2018

I route all the messages of my application to a custom logger, and when gravity is greater than warning I display the call stack and informations.

As i'm currently coding, there is a lot of warning :-), but I can live for the time without it, if it was your question.

@obastemur
Copy link
Collaborator

As linker dependency order matters, could you please try locating -lChakraCore before libunwind?

@lemmel
Copy link
Author

lemmel commented Feb 13, 2018

Same result with:

gcc -g -I/home/XXX/.root/Applications/ChakraCore/lib/Jsrt/ -L/home/XXX/.root/Applications/ChakraCore/out/Release -lChakraCore -lunwind -lunwind-x86_64  -pthread -lm -ldl -licuuc toto.cpp

@jianchun
Copy link

jianchun commented Mar 2, 2018

Can you try put -lgcc_s before libunwind? I recall seeing a problem of libunwind with ChakraCore/C++ exception before.

@lemmel
Copy link
Author

lemmel commented Mar 4, 2018

It does the trick but I'm not at ease with it, as gcc_s and libunwind can do the same thing: rewind stack trace.
I did some (very superficial) research, and by putting gcc_s on front, it seems that symbols of gcc_s are used at first, and symbols from libunwind used when its specific are called: they both provide some identical symbols.
So it seems that a mixed up of 2 libraries is done by adding gcc_s on the linker command line.

But for the time:

So I consider that I got a satisfactory answer, many thanks to @jianchun !

@lemmel lemmel closed this as completed Mar 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants