I've built v28.4.0 using gcc49, gcc5, gcc6 and the current version, 8.2.1. Gcc versions prior to gcc6 do not build (incompatible compiler option "-fno-plt"), and version from 6 on, although the build completes, they produce a version of palemoon that segfaults on startup.
Stack trace of thread 11503:
#0 0x00007fd1f628425f raise (libpthread.so.0)
#1 0x00007fd1f339a2f4 n/a (libxul.so)
#2 0x00007fd1f40b11a1 n/a (libxul.so)
#3 0x00007fd1f62843c0 __restore_rt (libpthread.so.0)
#4 0x00007fd1f6322005 _dl_relocate_object (ld-linux-x86-64.so.2)
#5 0x00007fd1f6329406 dl_open_worker (ld-linux-x86-64.so.2)
#6 0x00007fd1f5eb2f57 _dl_catch_exception (libc.so.6)
#7 0x00007fd1f6328dff _dl_open (ld-linux-x86-64.so.2)
#8 0x00007fd1f626e15a n/a (libdl.so.2)
#9 0x00007fd1f5eb2f57 _dl_catch_exception (libc.so.6)
#10 0x00007fd1f5eb2ff3 _dl_catch_error (libc.so.6)
#11 0x00007fd1f626e8bf n/a (libdl.so.2)
#12 0x00007fd1f626e1fa dlopen (libdl.so.2)
#13 0x00007fd1f62e7f9d PR_LoadLibraryWithFlags (libnspr4.so)
#14 0x00007fd1f295e001 n/a (libxul.so)
#15 0x00007fd1f296c33a n/a (libxul.so)
#16 0x00007fd1f296d7b1 n/a (libxul.so)
#17 0x00007fd1f2955ce2 n/a (libxul.so)
#18 0x00007fd1f2956392 n/a (libxul.so)
#19 0x00007fd1f2956513 n/a (libxul.so)
#20 0x00007fd1f2956cbf n/a (libxul.so)
#21 0x00007fd1f2956eae n/a (libxul.so)
#22 0x00007fd1f0e63819 NS_InvokeByIndex (libxul.so)
#23 0x00007fd1f16cf7c7 n/a (libxul.so)
#24 0x00007fd1f16d4b7e n/a (libxul.so)
#25 0x00007fd1f3f7f1ee n/a (libxul.so)
#26 0x00007fd1f3f79c0d n/a (libxul.so)
#27 0x00007fd1f3f7edf4 n/a (libxul.so)
#28 0x00007fd1f3f7f152 n/a (libxul.so)
#29 0x00007fd1f3f7f4c8 n/a (libxul.so)
#30 0x00007fd1f3ec2af0 n/a (libxul.so)
#31 0x00007fd1f3eb8fc1 n/a (libxul.so)
#32 0x00007fd1f3eb16c5 n/a (libxul.so)
#33 0x00007fd1f3eb2510 n/a (libxul.so)
#34 0x00007fd1f3f7f3b0 n/a (libxul.so)
#35 0x00007fd1f419b370 n/a (libxul.so)
#36 0x00002d05373bfa96 n/a (n/a)
#37 0x00007fd1dbd865e8 n/a (n/a)
#38 0x00002d05373be888 n/a (n/a)
#39 0x00007fd1f41719be n/a (libxul.so)
I know this issues has been logged here for earlier versions of palemoon. The last forum entry I read on this issue for v27.9 claimed that this problem was fixed - apparently it wasn't. I've also tried using the binary prebuilt - same problem.
I'm running on archlinux, kernel version 5.0.2.
Any ideas?
Palemoon 28.4.0 segfaults
Moderator: trava90
Forum rules
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
Re: Palemoon 28.4.0 segfaults
Since you built it yourself, please include:
- use flags, cxxflags system wide
- toolchain used
- mozconfig used
- a proper debug stack trace of the crash (call stack) with function references (looks like your stack trace didn't load symbols)
- use flags, cxxflags system wide
- toolchain used
- mozconfig used
- a proper debug stack trace of the crash (call stack) with function references (looks like your stack trace didn't load symbols)
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
-
Walter Dnes
- Astronaut
- Posts: 652
- Joined: 2015-07-30, 20:29
- Location: Vaughan, ON, Canada
Re: Palemoon 28.4.0 segfaults
Can you backtrack to the previous kernel version? 5.0.2 was released literally a couple of days ago (March 14) https://lwn.net/Articles/783068/ so it's quite new.jghodd wrote:I'm running on archlinux, kernel version 5.0.2.
Any ideas?
There's a right way
There's a wrong way
And then there's my way
There's a wrong way
And then there's my way
-
jghodd
Re: Palemoon 28.4.0 segfaults
Ok.
1) I won't be rolling back my kernel version - I'm a distro creator and 5.0.2 is the most recent kernel. It stays.
2) cxxflags doesn;t need to be set system wide. I've added whatever gcc version i'm using like this:
export CC=gcc-6
export CXX=g++-6
to my mozconfig.in and can see plainly during the build that whatever installed version of gcc I've built and installed is being run from the correct path. Also, one of the compiler options is only supported in gcc versions newer than 5 and I am getting the compiler error on that flag when cxxflags is set to an earlier version.
3) what compiler version do you suggest I use? as far as I'm concerned, the latest should suffice since there's no difference in the crash from gcc-5 onward. Please correct me if I'm wrong.
4) i'll add the -g flag and run it through gdb. i'll update when the build and test are done. takes about 8 hours to compile.
1) I won't be rolling back my kernel version - I'm a distro creator and 5.0.2 is the most recent kernel. It stays.
2) cxxflags doesn;t need to be set system wide. I've added whatever gcc version i'm using like this:
export CC=gcc-6
export CXX=g++-6
to my mozconfig.in and can see plainly during the build that whatever installed version of gcc I've built and installed is being run from the correct path. Also, one of the compiler options is only supported in gcc versions newer than 5 and I am getting the compiler error on that flag when cxxflags is set to an earlier version.
3) what compiler version do you suggest I use? as far as I'm concerned, the latest should suffice since there's no difference in the crash from gcc-5 onward. Please correct me if I'm wrong.
4) i'll add the -g flag and run it through gdb. i'll update when the build and test are done. takes about 8 hours to compile.
-
Walter Dnes
- Astronaut
- Posts: 652
- Joined: 2015-07-30, 20:29
- Location: Vaughan, ON, Canada
Re: Palemoon 28.4.0 segfaults
What is your mozconfig like? As per thread viewtopic.php?f=62&t=21375 I suggest for 64-bit
For 32-bit change "/usr/lib64" to "/usr/llib". And never ever --enable-system-<whatever>
Code: Select all
mk_add_options MOZ_CO_PROJECT=browser
ac_add_options --enable-application=palemoon
ac_add_options --enable-default-toolkit=cairo-gtk2
ac_add_options --enable-jemalloc
ac_add_options --enable-optimize="-O2 -msse2 -fomit-frame-pointer -pipe"
ac_add_options --enable-strip
ac_add_options --disable-accessibility
ac_add_options --disable-crashreporter
ac_add_options --disable-debug
ac_add_options --disable-necko-wifi
ac_add_options --disable-parental-controls
ac_add_options --disable-tests
ac_add_options --disable-updater
ac_add_options --with-pthreads
ac_add_options --x-libraries=/usr/lib64There's a right way
There's a wrong way
And then there's my way
There's a wrong way
And then there's my way
-
Walter Dnes
- Astronaut
- Posts: 652
- Joined: 2015-07-30, 20:29
- Location: Vaughan, ON, Canada
Re: Palemoon 28.4.0 segfaults
Part 2 of my reply
gcc -c -Q -march=native --help=target | grep march=
I'm building locally (on Gentoo) with 7.3.0 and it works fine.jghodd wrote:3) what compiler version do you suggest I use? as far as I'm concerned, the latest should suffice since there's no difference in the crash from gcc-5 onward. Please correct me if I'm wrong.
8 hours, ouch! What is your build system like? I.e. CPU and speed and how much RAM? I average near 50 minutes to build on a Dell Dimension 660 with a 4-core Ivybridge and 8 gigabytes of RAM. To find out your exact CPU model, executejghodd wrote:4) i'll add the -g flag and run it through gdb. i'll update when the build and test are done. takes about 8 hours to compile.
gcc -c -Q -march=native --help=target | grep march=
There's a right way
There's a wrong way
And then there's my way
There's a wrong way
And then there's my way
Re: Palemoon 28.4.0 segfaults
If it takes 8 hours to build there's definitely something very wrong.
Please note that if this is caused by insufficient RAM, causing the compiler and linker to swap, that your build may become (very) unstable and crash-prone. If you have enough RAM then something else is wrong and we'd need to find out exactly what.
Please note that if this is caused by insufficient RAM, causing the compiler and linker to swap, that your build may become (very) unstable and crash-prone. If you have enough RAM then something else is wrong and we'd need to find out exactly what.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
-
jghodd
Re: Palemoon 28.4.0 segfaults
No, there's nothing wrong. i'm running on an Intel Core Duo @ 2.6 ghz w/ 6G of RAM. 8 years of unemployment and practically $0 in donations for my distro means there's no way to upgrade beyond that... and 30 years of software engineering as a systems developer (RT and *nix systems) means I am definitely NOT out of my element - a little tired of putting in so much work without any return, so this has now turned into a hobby vs. a project. i.e. maybe a couple of hours a week vs 60 hours a week.
The default mozconfig.in does not preserve the debug symbols, so it's meaningless. I already provided the logfile output from the stripped version. In the time i've been willing to put in to resolving this for my user, i have yet to find the magic mozconfig formula to retain the symbol table for gdb. At this point, I'm about to throw in some printf's to PR_LoadLibraryWithFlags to figure out what's throwing it off. libxul.so appears to be an issue.
This is where I'm at at trying to build a version with intact symbol tables:
Suggestions would be welcome.
The default mozconfig.in does not preserve the debug symbols, so it's meaningless. I already provided the logfile output from the stripped version. In the time i've been willing to put in to resolving this for my user, i have yet to find the magic mozconfig formula to retain the symbol table for gdb. At this point, I'm about to throw in some printf's to PR_LoadLibraryWithFlags to figure out what's throwing it off. libxul.so appears to be an issue.
This is where I'm at at trying to build a version with intact symbol tables:
Code: Select all
ac_add_options --disable-jemalloc
ac_add_options --disable-crashreporter
ac_add_options --disable-elf-hack
ac_add_options --enable-pie
# Keep symbols to symbolize TSan traces
ac_add_options --disable-install-strip
#export CFLAGS="-g"
#export CXXFLAGS="-g"
#export MOZ_DEBUG_SYMBOLS=1
#ac_add_options --enable-debug-symbols="-gdwarf-2"
mk_add_options AUTOCLOBBER=1
mk_add_options MOZ_OBJDIR=%SRCDIR%/pmbuild
ac_add_options --enable-application=palemoon
ac_add_options --enable-debug-symbols
ac_add_options --disable-optimize
#ac_add_options --enable-optimize="-O2"
ac_add_options --enable-official-branding
export MOZILLA_OFFICIAL=1
ac_add_options --enable-default-toolkit=cairo-gtk2
#ac_add_options --enable-jemalloc
ac_add_options --disable-strip
ac_add_options --with-pthreads
ac_add_options --disable-tests
ac_add_options --disable-eme
ac_add_options --disable-parental-controls
ac_add_options --disable-accessibility
ac_add_options --disable-webrtc
ac_add_options --disable-gamepad
ac_add_options --disable-necko-wifi
ac_add_options --disable-updater
ac_add_options --x-libraries=/usr/lib
# Use python2
mk_add_options PYTHON=/usr/bin/python2
# uncomment the following to limit the number of parallel build jobs
# remember to run updpkgsums after, or you'll get a checksum failure
#mk_add_options MOZ_MAKE_FLAGS="-j4"
Re: Palemoon 28.4.0 segfaults
No, something isn't right. There has to be some bottleneck somewhere. I build the Mac OS releases on a core 2 duo @ 1.8ghz w/4gb ram and it only takes about 1.5 hours to build PM28 or Basilisk on that ancient machine. Even my archaic powerpc PowerMac G5 @2ghz can build PM in 2.5 hours.
Cheers
Cheers
Silence is golden, but duct tape is silver...
-
Walter Dnes
- Astronaut
- Posts: 652
- Joined: 2015-07-30, 20:29
- Location: Vaughan, ON, Canada
Re: Palemoon 28.4.0 segfaults
I agree. I fired up my old Core2 Duo with 3 gigabytes RAM and built the latest current mainline PM in under an hour and 3/4. (EDIT: This was 32-bit build on a 32-bit install). The output from "time ./build" (including packaging the tarball) waswicknix wrote:No, something isn't right. There has to be some bottleneck somewhere.
Code: Select all
real 98m4.416s
user 181m49.872s
sys 6m40.905s1) Is that a "Core2 Duo" or a "Core Duo". I don't see separate support for a "Core Duo" on the GCC website. At the command line, try the command...
gcc -c -Q -march=native --help=target | grep march=
...to get your exact CPU model.
2) Are you running a heavy-duty "desktop environment". Can you shut it off entirely to conserve memory?
3) Are your CPU cores running at their max speeds? Some machines run slower by default, and require a utility program to get the rated speed out of the CPU. At the commandline, what is the output of...
grep "cpu MHz" /proc/cpuinfo
There's a right way
There's a wrong way
And then there's my way
There's a wrong way
And then there's my way
-
jghodd
Re: Palemoon 28.4.0 segfaults
Core2. But honestly, I don't care how long it takes to build. I start it one day and may check back the next day to test it. Could take 24 hours to build as far as I'm concerned. What I need is the symbol table. What config changes do I need to make to mozconfig.in to build in debug mode and prevent the stripping. As far as I can tell, and from everything I've checked, I should have pretty close to what should be there, but the symbol table is still being stripped out of the build before packaging. Unfortunately, just about all the documentation for doing a debug build is out of date.
-
jghodd
Re: Palemoon 28.4.0 segfaults
OK. For those who want to do a debug build, the mozconfig.in I posted above is correct. If you're on Arch or an Arch-based distro and using makepkg, you have to add
to your PKGBUILD file.
The software is crashing when trying to dl-load libXt.so (which hasn't been updated since May '18. I rebuilt and reinstalled libxt, but it made no difference. Here's the stack trace:
Code: Select all
options=(debug !strip)The software is crashing when trying to dl-load libXt.so (which hasn't been updated since May '18. I rebuilt and reinstalled libxt, but it made no difference. Here's the stack trace:
Code: Select all
#0 0x00007ffff7fe0005 in _dl_relocate_object () at /lib64/ld-linux-x86-64.so.2
#1 0x00007ffff7fe7406 in dl_open_worker () at /lib64/ld-linux-x86-64.so.2
#2 0x00007ffff7ae9f57 in _dl_catch_exception () at /usr/lib/libc.so.6
#3 0x00007ffff7fe6dff in _dl_open () at /lib64/ld-linux-x86-64.so.2
#4 0x00007ffff7d2015a in () at /usr/lib/libdl.so.2
#5 0x00007ffff7ae9f57 in _dl_catch_exception () at /usr/lib/libc.so.6
#6 0x00007ffff7ae9ff3 in _dl_catch_error () at /usr/lib/libc.so.6
#7 0x00007ffff7d208bf in () at /usr/lib/libdl.so.2
#8 0x00007ffff7d201fa in dlopen () at /usr/lib/libdl.so.2
#9 0x00007ffff7d973c5 in pr_LoadLibraryByPathname (flags=6, name=0x5555570800a0 "libXt.so") at /usr/src/debug/UXP/nsprpub/pr/src/linking/prlink.c:806
#10 0x00007ffff7d973c5 in PR_LoadLibraryWithFlags (libSpec=..., flags=flags@entry=6) at /usr/src/debug/UXP/nsprpub/pr/src/linking/prlink.c:421
#11 0x00007ffff4746385 in LoadExtraSharedLib(char const*, char**, bool) (name=0x5555570800a0 "libXt.so", soname=0x7fffffff7540, tryToGetSoname=<optimized out>)
at /usr/src/debug/UXP/dom/plugins/base/nsPluginsDirUnix.cpp:89
#12 0x00007ffff4754b4e in LoadExtraSharedLibs () at /usr/src/debug/UXP/dom/plugins/base/nsPluginsDirUnix.cpp:175
#13 0x00007ffff4754b4e in nsPluginFile::LoadPlugin(PRLibrary**) (this=this@entry=0x7fffffff7ba0, outLibrary=outLibrary@entry=0x7fffffff7b88)
at /usr/src/debug/UXP/dom/plugins/base/nsPluginsDirUnix.cpp:293
#14 0x00007ffff4755c60 in nsPluginFile::GetPluginInfo(nsPluginInfo&, PRLibrary**) (this=this@entry=0x7fffffff7ba0, info=..., outLibrary=outLibrary@entry=0x7fffffff7b88)
at /usr/src/debug/UXP/dom/plugins/base/nsPluginsDirUnix.cpp:326
#15 0x00007ffff473de87 in nsPluginHost::ScanPluginsDirectory(nsIFile*, bool, bool*)
(this=<optimized out>, pluginsDir=<optimized out>, aCreatePluginList=<optimized out>, aPluginsChanged=<optimized out>)
at /usr/src/debug/UXP/dom/plugins/base/nsPluginHost.cpp:2151
#16 0x00007ffff473e31d in nsPluginHost::ScanPluginsDirectoryList(nsISimpleEnumerator*, bool, bool*) (this=this@entry=0x55555707aa00, dirEnum=
0x555556428bb0, aCreatePluginList=aCreatePluginList@entry=true, aPluginsChanged=aPluginsChanged@entry=0x7fffffff7e23) at /usr/src/debug/pmbuild/dist/include/nsCOMPtr.h:750
#17 0x00007ffff473e4cf in nsPluginHost::FindPlugins(bool, bool*) (aPluginsChanged=0x7fffffff7e9f, aCreatePluginList=true, this=0x55555707aa00)
at /usr/src/debug/pmbuild/dist/include/nsCOMPtr.h:750
#18 0x00007ffff473e4cf in nsPluginHost::FindPlugins(bool, bool*) (this=0x55555707aa00, aCreatePluginList=<optimized out>, aPluginsChanged=0x7fffffff7e9f)
at /usr/src/debug/UXP/dom/plugins/base/nsPluginHost.cpp:2407
#19 0x00007ffff473ebce in nsPluginHost::LoadPlugins() (this=0x55555707aa00) at /usr/src/debug/UXP/dom/plugins/base/nsPluginHost.cpp:2328
#20 0x00007ffff473ed93 in nsPluginHost::GetPluginTags(unsigned int*, nsIPluginTag***) (this=0x55555707aa00, aPluginCount=0x7fffffff8118, aResults=0x7fffffff8130)
at /usr/src/debug/UXP/dom/plugins/base/nsPluginHost.cpp:1155
#21 0x00007ffff2bd8b3b in NS_InvokeByIndex(nsISupports*, uint32_t, uint32_t, nsXPTCVariant*)
(that=<optimized out>, methodIndex=<optimized out>, paramCount=<optimized out>, params=<optimized out>)
at /usr/src/debug/UXP/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp:180
#22 0x00007ffff346ca43 in CallMethodHelper::Invoke() (this=0x7fffffff80d0) at /usr/src/debug/UXP/js/xpconnect/src/XPCWrappedNative.cpp:2061
#23 0x00007ffff346ca43 in CallMethodHelper::Call() (this=0x7fffffff80d0) at /usr/src/debug/UXP/js/xpconnect/src/XPCWrappedNative.cpp:1377
#24 0x00007ffff346ca43 in XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (ccx=..., mode=<optimized out>)
at /usr/src/debug/UXP/js/xpconnect/src/XPCWrappedNative.cpp:1344
#25 0x00007ffff34735fe in XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (cx=cx@entry=0x555555883390, argc=1, vp=<optimized out>)
at /usr/src/debug/UXP/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1000
#26 0x00007ffff5daafbd in js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&)
(args=..., native=0x7ffff3473360 <XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)>, cx=0x555555883390) at /usr/src/debug/pmbuild/dist/include/js/CallArgs.h:269
#27 0x00007ffff5daafbd in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) (cx=0x555555883390, args=..., construct=<optimized out>)
at /usr/src/debug/UXP/js/src/vm/Interpreter.cpp:457
#28 0x00007ffff5d9c779 in js::CallFromStack(JSContext*, JS::CallArgs const&) (args=..., cx=<optimized out>) at /usr/src/debug/UXP/js/src/vm/Interpreter.cpp:2990
#29 0x00007ffff5d9c779 in Interpret(JSContext*, js::RunState&) (cx=0x555555883390, state=...) at /usr/src/debug/UXP/js/src/vm/Interpreter.cpp:2990
#30 0x00007ffff5daa8ca in js::RunScript(JSContext*, js::RunState&) (cx=cx@entry=0x555555883390, state=...) at /usr/src/debug/UXP/js/src/vm/Interpreter.cpp:403
#31 0x00007ffff5daae96 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct)
(cx=cx@entry=0x555555883390, args=..., construct=construct@entry=js::NO_CONSTRUCT) at /usr/src/debug/UXP/js/src/vm/Interpreter.cpp:475
#32 0x00007ffff5dab199 in InternalCall(JSContext*, js::AnyInvokeArgs const&) (cx=cx@entry=0x555555883390, args=...) at /usr/src/debug/UXP/js/src/vm/Interpreter.cpp:502
#33 0x00007ffff5dab1f9 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>)
(cx=cx@entry=0x555555883390, fval=..., fval@entry=..., thisv=..., args=..., rval=...) at /usr/src/debug/UXP/js/src/vm/Interpreter.cpp:521
#34 0x00007ffff5ce9b97 in js::Wrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) const
(this=this@entry=0x7ffff7372b40 <js::CrossCompartmentWrapper::singleton>, cx=cx@entry=0x555555883390, proxy=..., proxy@entry=..., args=...)
at /usr/src/debug/pmbuild/dist/include/js/RootingAPI.h:1004
#35 0x00007ffff5cdfcb1 in js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) const
(this=0x7ffff7372b40 <js::CrossCompartmentWrapper::singleton>, cx=0x555555883390, wrapper=..., args=...) at /usr/src/debug/UXP/js/src/proxy/CrossCompartmentWrapper.cpp:333
#36 0x00007ffff5cd79bd in js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (cx=cx@entry=0x555555883390, proxy=proxy@entry=..., args=...)
at /usr/src/debug/UXP/js/src/proxy/Proxy.cpp:400
#37 0x00007ffff5cd87ed in js::proxy_Call(JSContext*, unsigned int, JS::Value*) (cx=cx@entry=0x555555883390, argc=<optimized out>, vp=<optimized out>)
at /usr/src/debug/pmbuild/dist/include/js/RootingAPI.h:1004
#38 0x00007ffff5dab095 in js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&)
(args=..., native=0x7ffff5cd8770 <js::proxy_Call(JSContext*, unsigned int, JS::Value*)>, cx=0x555555883390) at /usr/src/debug/pmbuild/dist/include/js/CallArgs.h:269
#39 0x00007ffff5dab095 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct)
(cx=cx@entry=0x555555883390, args=..., construct=construct@entry=js::NO_CONSTRUCT) at /usr/src/debug/UXP/js/src/vm/Interpreter.cpp:445
#40 0x00007ffff5dab199 in InternalCall(JSContext*, js::AnyInvokeArgs const&) (cx=cx@entry=0x555555883390, args=...) at /usr/src/debug/UXP/js/src/vm/Interpreter.cpp:502
#41 0x00007ffff5dab1c5 in js::CallFromStack(JSContext*, JS::CallArgs const&) (cx=cx@entry=0x555555883390, args=...) at /usr/src/debug/UXP/js/src/vm/Interpreter.cpp:508
#42 0x00007ffff5fd03e4 in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, uint32_t, JS::Value*, JS::MutableHandleValue)
(cx=0x555555883390, frame=0x7fffffff9198, stub_=0x555556a66528, argc=1, vp=0x7fffffff9138, res=...) at /usr/src/debug/UXP/js/src/jit/BaselineIC.cpp:6020
#43 0x00002cb764118a96 in ()
#44 0x00007fffd8137f10 in ()
#45 0x00007fffffff90f0 in ()
#46 0xfff9000000000000 in ()
#47 0x00007ffff7510420 in js::jit::DoCallFallbackInfo () at /usr/lib/palemoon/libxul.so
#48 0x00007fffec571520 in ()
#49 0x00002cb7641af053 in ()
#50 0x0000000000004822 in ()
#51 0x00007fffffff9198 in ()
#52 0x0000555556a66528 in ()
#53 0x0000000000000001 in ()
#54 0x00007fffffff9138 in ()
#55 0xfffe7fffd818b240 in ()
#56 0xfffe7fffd80135e0 in ()
#57 0xfffe7fffa44bf080 in ()
#58 0x00007fffffff91c8 in ()
#59 0x0000555556a66528 in ()
#60 0x00002cb7641fd74d in ()
#61 0x0000000000006021 in ()
#62 0xfffe7fffa44b9780 in ()
#63 0xfffe7fffd81fb960 in ()
#64 0xfffe7fffd81d2740 in ()
#65 0xfffa80000000000f in ()
#66 0xfffe7fffd8176ec0 in ()
#67 0x0000000000000094 in ()
#68 0x0000000000000000 in ()-
jghodd
Re: Palemoon 28.4.0 segfaults
Apparently, palemoon and freshplayerplugin are incompatible co-installations. Remove freshplayerplugin and it runs - viewtopic.php?t=17638