Webkit/JavascriptCore did not work with musl libc

Webkit/JavascriptCore did not work with musl libc

[黄建忠]

Hi, all,
I build webkitgtk-2.4.4 and ewebkit2 under musl libc with
gcc-4.9.1(patched) and clang-3.5, the javascriptCore js engine did not
work as expected(with JIT enable or disable.)

for webkitgtk, jsc just output "Exception:" when run any js codes.
for ewebkit2, jsc just segfault with below backtrace:

#0 0x00000000008cf0c4 in WTFCrash ()
#1 0x000000000065bb72 in WTF::PassRefPtr<JSC::ProgramNode>
JSC::parse<JSC::ProgramNode>(JSC::VM*, JSC::SourceCode const&,
JSC::FunctionParameters*, JSC::Identifier const&,
JSC::JSParserStrictness, JSC::JSParserMode, JSC::ParserError&,
JSC::JSTextPosition*, bool) ()
#2 0x000000000077c6f0 in
JSC::BuiltinExecutables::createBuiltinExecutable(JSC::SourceCode const&,
JSC::Identifier const&) ()
#3 0x000000000077cc73 in
JSC::BuiltinExecutables::functionPrototypeApplyCodeExecutable() ()
#4 0x000000000076ee90 in
JSC::functionPrototypeApplyCodeGenerator(JSC::VM&) ()
#5 0x00000000007c1a78 in
JSC::FunctionPrototype::addFunctionProperties(JSC::ExecState*,
JSC::JSGlobalObject*, JSC::JSFunction**, JSC::JSFunction**) ()
#6 0x0000000000682f89 in JSC::JSGlobalObject::reset(JSC::JSValue) ()
#7 0x00000000004f68c1 in JSC::JSGlobalObject::finishCreation(JSC::VM&) ()
#8 0x00000000004f600c in GlobalObject::finishCreation(JSC::VM&,
WTF::Vector<WTF::String, 0ul, WTF::CrashOnOverflow> const&) ()
#9 0x00000000004f01b8 in jscmain(int, char**) ()
#10 0x00000000004eff5d in main ()

The JSCore codes is too complex and I even can not figure out the buggy
codes quickly.

My environment is a customized linux with musl libc/wayland
only/gcc/clang/systemd and so on.

can Anybody who use a musl libc based distribution try and check it? for
webkitgtk2, there is no need to build it completely, just:
configure and "make jsc" then try it.

I am also working on it.

-- 
Huang JianZhong

Re: Webkit/JavascriptCore did not work with musl libc

[Natanael Copa]

On Wed, 15 Oct 2014 13:58:42 +0800
*** <jianzhong.huang@i-soft.com.cn> wrote:

> Hi, all,
> I build webkitgtk-2.4.4 and ewebkit2 under musl libc with
> gcc-4.9.1(patched) and clang-3.5, the javascriptCore js engine did not
> work as expected(with JIT enable or disable.)
> 
> for webkitgtk, jsc just output "Exception:" when run any js codes.
> for ewebkit2, jsc just segfault with below backtrace:
> 
> #0 0x00000000008cf0c4 in WTFCrash ()
> #1 0x000000000065bb72 in WTF::PassRefPtr<JSC::ProgramNode>
> JSC::parse<JSC::ProgramNode>(JSC::VM*, JSC::SourceCode const&,
> JSC::FunctionParameters*, JSC::Identifier const&,
> JSC::JSParserStrictness, JSC::JSParserMode, JSC::ParserError&,
> JSC::JSTextPosition*, bool) ()
> #2 0x000000000077c6f0 in
> JSC::BuiltinExecutables::createBuiltinExecutable(JSC::SourceCode const&,
> JSC::Identifier const&) ()
> #3 0x000000000077cc73 in
> JSC::BuiltinExecutables::functionPrototypeApplyCodeExecutable() ()
> #4 0x000000000076ee90 in
> JSC::functionPrototypeApplyCodeGenerator(JSC::VM&) ()
> #5 0x00000000007c1a78 in
> JSC::FunctionPrototype::addFunctionProperties(JSC::ExecState*,
> JSC::JSGlobalObject*, JSC::JSFunction**, JSC::JSFunction**) ()
> #6 0x0000000000682f89 in JSC::JSGlobalObject::reset(JSC::JSValue) ()
> #7 0x00000000004f68c1 in JSC::JSGlobalObject::finishCreation(JSC::VM&) ()
> #8 0x00000000004f600c in GlobalObject::finishCreation(JSC::VM&,
> WTF::Vector<WTF::String, 0ul, WTF::CrashOnOverflow> const&) ()
> #9 0x00000000004f01b8 in jscmain(int, char**) ()
> #10 0x00000000004eff5d in main ()
> 
> The JSCore codes is too complex and I even can not figure out the buggy
> codes quickly.
> 
> My environment is a customized linux with musl libc/wayland
> only/gcc/clang/systemd and so on.
> 
> can Anybody who use a musl libc based distribution try and check it? for
> webkitgtk2, there is no need to build it completely, just:
> configure and "make jsc" then try it.

Alpine Linux, x86_64, musl-1.1.5, gcc (Alpine 4.8.3) 4.8.3


ncopa-desktop:~$ apk version webkitgtk
Installed:                                Available:
webkitgtk-2.4.5-r1                      = 2.4.5-r1 

ncopa-desktop:~$ jsc-3
"hello"
>>> Exception: RangeError: Maximum call stack size exceeded.


Maybe the thread stack needs to be increased?

> 
> I am also working on it.
> 

-nc

Re: Webkit/JavascriptCore did not work with musl libc

[黄建忠]

Thanks for you feedback.

I notice alpine, it's greate and I also take a lot of patches from it 
when building my dist.(RPM based, support systemd/wayland-only).

But I found there is no "check" (make check, make test, make tests etc.) 
in alpine build system.

According my work, a lot of base components will fail under musl libc, 
and I already fix most of them(when it's ready, I will release all codes.).

At the same time, It's also a heavy and useful testing for musl. At 
least, I can say Musl is good enough and ready to use(Locale support is 
poor, need more work.)

于 2014年10月15日 18:02, Natanael Copa 写道:
> On Wed, 15 Oct 2014 13:58:42 +0800
> *** <jianzhong.huang@i-soft.com.cn> wrote:
>
>> Hi, all,
>> I build webkitgtk-2.4.4 and ewebkit2 under musl libc with
>> gcc-4.9.1(patched) and clang-3.5, the javascriptCore js engine did not
>> work as expected(with JIT enable or disable.)
>>
>> for webkitgtk, jsc just output "Exception:" when run any js codes.
>> for ewebkit2, jsc just segfault with below backtrace:
>>
>> #0 0x00000000008cf0c4 in WTFCrash ()
>> #1 0x000000000065bb72 in WTF::PassRefPtr<JSC::ProgramNode>
>> JSC::parse<JSC::ProgramNode>(JSC::VM*, JSC::SourceCode const&,
>> JSC::FunctionParameters*, JSC::Identifier const&,
>> JSC::JSParserStrictness, JSC::JSParserMode, JSC::ParserError&,
>> JSC::JSTextPosition*, bool) ()
>> #2 0x000000000077c6f0 in
>> JSC::BuiltinExecutables::createBuiltinExecutable(JSC::SourceCode const&,
>> JSC::Identifier const&) ()
>> #3 0x000000000077cc73 in
>> JSC::BuiltinExecutables::functionPrototypeApplyCodeExecutable() ()
>> #4 0x000000000076ee90 in
>> JSC::functionPrototypeApplyCodeGenerator(JSC::VM&) ()
>> #5 0x00000000007c1a78 in
>> JSC::FunctionPrototype::addFunctionProperties(JSC::ExecState*,
>> JSC::JSGlobalObject*, JSC::JSFunction**, JSC::JSFunction**) ()
>> #6 0x0000000000682f89 in JSC::JSGlobalObject::reset(JSC::JSValue) ()
>> #7 0x00000000004f68c1 in JSC::JSGlobalObject::finishCreation(JSC::VM&) ()
>> #8 0x00000000004f600c in GlobalObject::finishCreation(JSC::VM&,
>> WTF::Vector<WTF::String, 0ul, WTF::CrashOnOverflow> const&) ()
>> #9 0x00000000004f01b8 in jscmain(int, char**) ()
>> #10 0x00000000004eff5d in main ()
>>
>> The JSCore codes is too complex and I even can not figure out the buggy
>> codes quickly.
>>
>> My environment is a customized linux with musl libc/wayland
>> only/gcc/clang/systemd and so on.
>>
>> can Anybody who use a musl libc based distribution try and check it? for
>> webkitgtk2, there is no need to build it completely, just:
>> configure and "make jsc" then try it.
> Alpine Linux, x86_64, musl-1.1.5, gcc (Alpine 4.8.3) 4.8.3
>
>
> ncopa-desktop:~$ apk version webkitgtk
> Installed:                                Available:
> webkitgtk-2.4.5-r1                      = 2.4.5-r1
>
> ncopa-desktop:~$ jsc-3
> "hello"
>>>> Exception: RangeError: Maximum call stack size exceeded.
>
> Maybe the thread stack needs to be increased?
>
>> I am also working on it.
>>
> -nc
>


-- 
Huang JianZhong

Re: Webkit/JavascriptCore did not work with musl libc

[Rich Felker]

On Thu, Oct 16, 2014 at 09:53:01AM +0800, 黄建忠 wrote:
> Thanks for you feedback.
> 
> I notice alpine, it's greate and I also take a lot of patches from
> it when building my dist.(RPM based, support systemd/wayland-only).
> 
> But I found there is no "check" (make check, make test, make tests
> etc.) in alpine build system.
> 
> According my work, a lot of base components will fail under musl
> libc, and I already fix most of them(when it's ready, I will release
> all codes.).
> 
> At the same time, It's also a heavy and useful testing for musl. At
> least, I can say Musl is good enough and ready to use(Locale support
> is poor, need more work.)

Just the lack of any pre-made locales, or something else you're
missing?

Rich

Re: Webkit/JavascriptCore did not work with musl libc

[黄建忠]

Hmm...
C/posix equals to UTF8,  some testcase need to adjust.
Lack of predefined locale, there are some locale-dependent codes. for 
example, seperators, date time format, locale-dependent sort etc. It's 
buggy to write locale-dependent codes but it exist.

Another problem about multilingul is the poor iconv,  some source may 
compiled but not works as expected. gnu/libiconv can be used as a 
suppliment, but there are also some testcase can not pass.

于 2014年10月16日 10:08, Rich Felker 写道:
> On Thu, Oct 16, 2014 at 09:53:01AM +0800, 黄建忠 wrote:
>> Thanks for you feedback.
>>
>> I notice alpine, it's greate and I also take a lot of patches from
>> it when building my dist.(RPM based, support systemd/wayland-only).
>>
>> But I found there is no "check" (make check, make test, make tests
>> etc.) in alpine build system.
>>
>> According my work, a lot of base components will fail under musl
>> libc, and I already fix most of them(when it's ready, I will release
>> all codes.).
>>
>> At the same time, It's also a heavy and useful testing for musl. At
>> least, I can say Musl is good enough and ready to use(Locale support
>> is poor, need more work.)
> Just the lack of any pre-made locales, or something else you're
> missing?
>
> Rich
>


-- 
Huang JianZhong

Re: Webkit/JavascriptCore did not work with musl libc

[Szabolcs Nagy]

* ????????? <jianzhong.huang@i-soft.com.cn> [2014-10-16 14:28:19 +0800]:
> C/posix equals to UTF8,  some testcase need to adjust.
> Lack of predefined locale, there are some locale-dependent codes. for
> example, seperators, date time format, locale-dependent sort etc. It's buggy
> to write locale-dependent codes but it exist.

whether the C locale should be allowed to be utf8 is debated by the
posix committee, but the current c and posix standards allow it

locale dependent encoding can break many things (encoding depends on
globals and/or thread local data) and there is no reason not to use
the same encoding (utf8) for all locales (special encodings can be
handled by iconv or other apis without global state)

if you know of situations where musl does not work, but should
then please report it

> Another problem about multilingul is the poor iconv,  some source may
> compiled but not works as expected. gnu/libiconv can be used as a
> suppliment, but there are also some testcase can not pass.

can you give examples of issues?

musl iconv should support most relevant encodings

if you know of missing but widely used ones then please report them

Re: Webkit/JavascriptCore did not work with musl libc

[黄建忠]

By the way, would you like to try:
"jsc --options" and adjust some settings of jsc to run it again?

于 2014年10月15日 18:02, Natanael Copa 写道:
> On Wed, 15 Oct 2014 13:58:42 +0800
> *** <jianzhong.huang@i-soft.com.cn> wrote:
>
>> Hi, all,
>> I build webkitgtk-2.4.4 and ewebkit2 under musl libc with
>> gcc-4.9.1(patched) and clang-3.5, the javascriptCore js engine did not
>> work as expected(with JIT enable or disable.)
>>
>> for webkitgtk, jsc just output "Exception:" when run any js codes.
>> for ewebkit2, jsc just segfault with below backtrace:
>>
>> #0 0x00000000008cf0c4 in WTFCrash ()
>> #1 0x000000000065bb72 in WTF::PassRefPtr<JSC::ProgramNode>
>> JSC::parse<JSC::ProgramNode>(JSC::VM*, JSC::SourceCode const&,
>> JSC::FunctionParameters*, JSC::Identifier const&,
>> JSC::JSParserStrictness, JSC::JSParserMode, JSC::ParserError&,
>> JSC::JSTextPosition*, bool) ()
>> #2 0x000000000077c6f0 in
>> JSC::BuiltinExecutables::createBuiltinExecutable(JSC::SourceCode const&,
>> JSC::Identifier const&) ()
>> #3 0x000000000077cc73 in
>> JSC::BuiltinExecutables::functionPrototypeApplyCodeExecutable() ()
>> #4 0x000000000076ee90 in
>> JSC::functionPrototypeApplyCodeGenerator(JSC::VM&) ()
>> #5 0x00000000007c1a78 in
>> JSC::FunctionPrototype::addFunctionProperties(JSC::ExecState*,
>> JSC::JSGlobalObject*, JSC::JSFunction**, JSC::JSFunction**) ()
>> #6 0x0000000000682f89 in JSC::JSGlobalObject::reset(JSC::JSValue) ()
>> #7 0x00000000004f68c1 in JSC::JSGlobalObject::finishCreation(JSC::VM&) ()
>> #8 0x00000000004f600c in GlobalObject::finishCreation(JSC::VM&,
>> WTF::Vector<WTF::String, 0ul, WTF::CrashOnOverflow> const&) ()
>> #9 0x00000000004f01b8 in jscmain(int, char**) ()
>> #10 0x00000000004eff5d in main ()
>>
>> The JSCore codes is too complex and I even can not figure out the buggy
>> codes quickly.
>>
>> My environment is a customized linux with musl libc/wayland
>> only/gcc/clang/systemd and so on.
>>
>> can Anybody who use a musl libc based distribution try and check it? for
>> webkitgtk2, there is no need to build it completely, just:
>> configure and "make jsc" then try it.
> Alpine Linux, x86_64, musl-1.1.5, gcc (Alpine 4.8.3) 4.8.3
>
>
> ncopa-desktop:~$ apk version webkitgtk
> Installed:                                Available:
> webkitgtk-2.4.5-r1                      = 2.4.5-r1
>
> ncopa-desktop:~$ jsc-3
> "hello"
>>>> Exception: RangeError: Maximum call stack size exceeded.
>
> Maybe the thread stack needs to be increased?
>
>> I am also working on it.
>>
> -nc
>


-- 
Huang JianZhong

Re: Webkit/JavascriptCore did not work with musl libc

[黄建忠]

Since it's a open issue in this maillist, I think it's better to have a 
feed back.

JsCore range error problem fixed for webkitgtk-2.4.x and webkit bundled 
in Qt(Qt 5.3.x, Qt4 should works but not tested now.).

-    const size_t requiredStack = 128 * KB;
-    const size_t errorModeRequiredStack = 64 * KB;
+    const size_t requiredStack = 32 * KB;
+    const size_t errorModeRequiredStack = 16 * KB;


For ewebkit/webkitgtk-2.6(AKA, webkitgtk4), they all use the latest 
codebase of webkit, and had the same issue but different from 
webkitgtk-2.4.x.
I will try to fix it later since webkitgtk-2.4 is enough from my system.

Alpine guys can check this patch and have a try.

By the way, QSslSocket in alpine linux still had a problem about loading 
libssl.
In qsslsocket_openssl_symbols.cpp:
  #ifdef Q_OS_OPENBSD
libcrypto->setLoadHints(QLibrary::ExportExternalSymbolsHint);
  #endif
+ libcrypto->setLoadHints(QLibrary::ExportExternalSymbolsHint);
+    libssl->setLoadHints(QLibrary::ExportExternalSymbolsHint);

Otherwise, the symbol resolving of libssl will fail, at least with 
libressl, I think it's same for openssl.

在 10/15/14 18:02, Natanael Copa 写道:
> On Wed, 15 Oct 2014 13:58:42 +0800
> *** <jianzhong.huang@i-soft.com.cn> wrote:
>
>> Hi, all,
>> I build webkitgtk-2.4.4 and ewebkit2 under musl libc with
>> gcc-4.9.1(patched) and clang-3.5, the javascriptCore js engine did not
>> work as expected(with JIT enable or disable.)
>>
>> for webkitgtk, jsc just output "Exception:" when run any js codes.
>> for ewebkit2, jsc just segfault with below backtrace:
>>
>> #0 0x00000000008cf0c4 in WTFCrash ()
>> #1 0x000000000065bb72 in WTF::PassRefPtr<JSC::ProgramNode>
>> JSC::parse<JSC::ProgramNode>(JSC::VM*, JSC::SourceCode const&,
>> JSC::FunctionParameters*, JSC::Identifier const&,
>> JSC::JSParserStrictness, JSC::JSParserMode, JSC::ParserError&,
>> JSC::JSTextPosition*, bool) ()
>> #2 0x000000000077c6f0 in
>> JSC::BuiltinExecutables::createBuiltinExecutable(JSC::SourceCode const&,
>> JSC::Identifier const&) ()
>> #3 0x000000000077cc73 in
>> JSC::BuiltinExecutables::functionPrototypeApplyCodeExecutable() ()
>> #4 0x000000000076ee90 in
>> JSC::functionPrototypeApplyCodeGenerator(JSC::VM&) ()
>> #5 0x00000000007c1a78 in
>> JSC::FunctionPrototype::addFunctionProperties(JSC::ExecState*,
>> JSC::JSGlobalObject*, JSC::JSFunction**, JSC::JSFunction**) ()
>> #6 0x0000000000682f89 in JSC::JSGlobalObject::reset(JSC::JSValue) ()
>> #7 0x00000000004f68c1 in JSC::JSGlobalObject::finishCreation(JSC::VM&) ()
>> #8 0x00000000004f600c in GlobalObject::finishCreation(JSC::VM&,
>> WTF::Vector<WTF::String, 0ul, WTF::CrashOnOverflow> const&) ()
>> #9 0x00000000004f01b8 in jscmain(int, char**) ()
>> #10 0x00000000004eff5d in main ()
>>
>> The JSCore codes is too complex and I even can not figure out the buggy
>> codes quickly.
>>
>> My environment is a customized linux with musl libc/wayland
>> only/gcc/clang/systemd and so on.
>>
>> can Anybody who use a musl libc based distribution try and check it? for
>> webkitgtk2, there is no need to build it completely, just:
>> configure and "make jsc" then try it.
> Alpine Linux, x86_64, musl-1.1.5, gcc (Alpine 4.8.3) 4.8.3
>
>
> ncopa-desktop:~$ apk version webkitgtk
> Installed:                                Available:
> webkitgtk-2.4.5-r1                      = 2.4.5-r1
>
> ncopa-desktop:~$ jsc-3
> "hello"
>>>> Exception: RangeError: Maximum call stack size exceeded.
>
> Maybe the thread stack needs to be increased?
>
>> I am also working on it.
>>
> -nc
>


-- 
Huang JianZhong