Browsers which are based on net-libs/webkit-gtk-2.0.4 always crash when brwosing a web site with Javascript enabled (using amd64 hardened). Viewing the pages with Javascript disabled is no problem. The core dump is from xombrero (www-client/xombrero-1.6.1), but the issue is the same for www-client/midori-0.5.4. On the other hand I have no problems with qupzilla (www-client/qupzilla-1.4.3, dev-qt/qtwebkit-4.8.5). Reproducible: Always Steps to Reproduce: 1. Brwose as website employing Javascript (Javascript disabled) 2. Toggle Javascript on or 1. Brwose as website employing Javascript (Javascript enabled) Actual Results: Browser crashes on relaoding the page
Created attachment 358342 [details] backtrace of xombrero after crash
Created attachment 358344 [details] output of cave info webkit-gtk
(In reply to Christian Apeltauer from comment #1) > 0x2d128953ece /usr/lib64/libjavascriptcoregtk-3.0.so.0(_ZN3JSC4Yarr10jitCompileERNS0_11YarrPatternENS0_12YarrCharSizeEPNS_12JSGlobalDataERNS0_13YarrCodeBlockENS0_18YarrJITCompileModeE+0x8e) [0x2d128953ece] Well, the general gist seems to be that jit compilation is being attempted on a PaX system, which leads to the kernel killing the process. First, please verify, you built webkit-gtk with the jit USE flag disabled? (I don't use paludis, so I am not sure if I read cave output correctly.) Second, could you get a backtrace using gdb or something which demangles c++ symbols ("_ZN3JSC...") into a human-readable form?
Also, as a quick workaround until this is fixed, you can do paxctl m /usr/bin/xombrero to allow the executable to use jit on a PaX system.
I think this is caused by jit in webkit-gtk's Yarr regular expression library getting enabled even if you configure with --disable-jit :/ Take a look at the following awesome logic in Platform.h: /* If the jit is not available, enable the LLInt C Loop: */ #if !ENABLE(JIT) #undef ENABLE_LLINT /* Undef so that we can redefine it. */ #undef ENABLE_LLINT_C_LOOP /* Undef so that we can redefine it. */ #undef ENABLE_DFG_JIT /* Undef so that we can redefine it. */ #define ENABLE_LLINT 1 #define ENABLE_LLINT_C_LOOP 1 #define ENABLE_DFG_JIT 0 #endif [...] #if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT) || ENABLE(LLINT_C_LOOP)) && !PLATFORM(CHROMIUM) && !(OS(QNX) && PLATFORM(QT)) #define ENABLE_YARR_JIT 1 So, we need a patch to ensure "--disable-jit" means really disable jit.
(In reply to Alexandre Rostovtsev from comment #3) > (In reply to Christian Apeltauer from comment #1) > > > 0x2d128953ece /usr/lib64/libjavascriptcoregtk-3.0.so.0(_ZN3JSC4Yarr10jitCompileERNS0_11YarrPatternENS0_12YarrCharSizeEPNS_12JSGlobalDataERNS0_13YarrCodeBlockENS0_18YarrJITCompileModeE+0x8e) [0x2d128953ece] > > Well, the general gist seems to be that jit compilation is being attempted > on a PaX system, which leads to the kernel killing the process. > > First, please verify, you built webkit-gtk with the jit USE flag disabled? > (I don't use paludis, so I am not sure if I read cave output correctly.) > The jit USE flag was definitively disabled when I compiled webkit-gtk.
Created attachment 358456 [details] demangled backtrace
I ran across the same problem when trying to use epiphany. Based upon the information here, the following patch actually "fixed" the problem: <<<>>> diff --git a/webkitgtk-2.0.4/Source/WTF/wtf/Platform.h b/webkitgtk-2.0.4/Source/WTF/wtf/Platform.h index 2d90359..2ab667e 100644 --- a/webkitgtk-2.0.4/Source/WTF/wtf/Platform.h +++ b/webkitgtk-2.0.4/Source/WTF/wtf/Platform.h @@ -772,7 +772,7 @@ && (OS(DARWIN) || !COMPILER(GCC) || GCC_VERSION_AT_LEAST(4, 1, 0)) \ && !OS(WINCE) \ && !(OS(QNX) && !PLATFORM(QT)) /* We use JIT in QNX Qt */ -#define ENABLE_JIT 1 +#define ENABLE_JIT 0 /*tmp fix for gentoo hardened */ #endif /* If possible, try to enable a disassembler. This is optional. We proceed in two <<<>>> A less time consuming workaround consists in disabling java script individually, by using the gsettings utility program: $ gsettings set org.gnome.Epiphany.web enable-javascript false The irony is that the webkit-gtk-2.0.4 ebuild does call paxctl on several executables only if the use flag jit was set. So the combination of enabling the jit use flag and the use of "gsettings" might make the system to behave correctly until the funny logic in Platform.h had been fixed.
*** Bug 493636 has been marked as a duplicate of this bug. ***
*** Bug 493708 has been marked as a duplicate of this bug. ***
(In reply to Hugo Mildenberger from comment #8) > I ran across the same problem when trying to use epiphany. Based upon the > information here, the following patch actually "fixed" the problem: > > > <<<>>> > diff --git a/webkitgtk-2.0.4/Source/WTF/wtf/Platform.h > b/webkitgtk-2.0.4/Source/WTF/wtf/Platform.h > index 2d90359..2ab667e 100644 > --- a/webkitgtk-2.0.4/Source/WTF/wtf/Platform.h > +++ b/webkitgtk-2.0.4/Source/WTF/wtf/Platform.h > @@ -772,7 +772,7 @@ > && (OS(DARWIN) || !COMPILER(GCC) || GCC_VERSION_AT_LEAST(4, 1, 0)) \ > && !OS(WINCE) \ > && !(OS(QNX) && !PLATFORM(QT)) /* We use JIT in QNX Qt */ > -#define ENABLE_JIT 1 > +#define ENABLE_JIT 0 /*tmp fix for gentoo hardened */ > #endif > > /* If possible, try to enable a disassembler. This is optional. We proceed > in two > <<<>>> > > > > A less time consuming workaround consists in disabling java script > individually, by using the gsettings utility program: > > $ gsettings set org.gnome.Epiphany.web enable-javascript false > > The irony is that the webkit-gtk-2.0.4 ebuild does call paxctl on several > executables only if the use flag jit was set. So the combination of enabling > the jit use flag and the use of "gsettings" might make the system to behave > correctly until the funny logic in Platform.h had been fixed. Can you give me the dmesg? JIT almost always leads to a denied rwx mmap uner a pax hardened kernel, which may be annoying, but is what you want from a security point of view. All packages which have JIT should have a USE=jit flag which we mask in hardened.
(In reply to Anthony Basile from comment #11) > Can you give me the dmesg? JIT almost always leads to a denied rwx mmap > uner a pax hardened kernel, which may be annoying, but is what you want from > a security point of view. All packages which have JIT should have a USE=jit > flag which we mask in hardened. The issue is that in 2.0.4 USE=-jit turns off javascript jit, but leaves regex jit enabled. And there is no configure switch to turn off what we want, and no more than that.
(In reply to Alexandre Rostovtsev from comment #12) > (In reply to Anthony Basile from comment #11) > > Can you give me the dmesg? JIT almost always leads to a denied rwx mmap > > uner a pax hardened kernel, which may be annoying, but is what you want from > > a security point of view. All packages which have JIT should have a USE=jit > > flag which we mask in hardened. > > The issue is that in 2.0.4 USE=-jit turns off javascript jit, but leaves > regex jit enabled. And there is no configure switch to turn off what we > want, and no more than that. Yeah Zorry just explained that. So how about something simple like use pax_kernel && sed -i 's:ENABLE_JIT 1:ENABLE_JIT 0:' Platform.h in src_prepare().
(In reply to Hugo Mildenberger from comment #8) > The irony is that the webkit-gtk-2.0.4 ebuild does call paxctl on several > executables only if the use flag jit was set. So the combination of enabling > the jit use flag and the use of "gsettings" might make the system to behave > correctly until the funny logic in Platform.h had been fixed. pax marking should always be done unconditionally. Only in rare cases is it unsafe to do so.
Try with 2.2.6 as it disables JIT on more places now when the USE is off
(In reply to Pacho Ramos from comment #15) > Try with 2.2.6 as it disables JIT on more places now when the USE is off Also with 2.4.4
