lacoste segfault Topic is solved

[smoki]

Pale Moon 28.8.3 segfaulting on this site:

https://www.lacoste.com/us/

OK, seems regression as working on 28.7.2 and with 28.8.x serie starts crashing

BTW, Debian 10 32bit, using stevepusser's repo... just to mention, as always might be related might not

[Moonchild]

BTW, Debian 10 32bit, using stevepusser's repo... just to mention, as always might be related might not

Please provide more details.

- details of the crash/segfault
- desktop environment you are working in
- troubleshooting information from the browser

(Does not reproduce on Windows for me)

By the way, for this site to work you will need to disable ES6 module scripting as their use of it doesn't like our basic implementation, and will refuse to work properly. (dom.moduleScripts.enabled)

[smoki]

Not sure how to get more info, as it seems does not create anything... if i try to start palemoon from terminal emulator and go to that site then browser closes up and just say there "Segmentation fault".

But yeah if i disable dom.moduleScripts it does not segfault anymore

[stevenpusser]

The crash is also reproducible on MX 19's 64-bit build, which basically should be identical to the Buster version in my repo, as soon as I click anywhere on the site. Pale Moon just reports a segmentation fault when started from a terminal.

The desktop is MX's backport of XFCE 4.14.2 to Buster.

Disabling dom.moduleScripts also stops the crashes there.

[New Tobin Paradigm]

Sounds like you will have to enable debug symbols and debug it. Does this happen on the mainline linux builds?

[ron_1]

New Tobin Paradigm wrote:
Does this happen on the mainline linux builds?

I'm using the mainline Linux build 64 bit, on Devuan 64 bit, and it crashed without warning or error message after a couple of clicks.

[New Tobin Paradigm]

Thanks for the report.

[New Tobin Paradigm]

I was able to get it to crash on Windows at tip.

Exception: c0000005

The thread 0xdfc has exited with code 0 (0x0).
Unhandled exception thrown: read access violation.
ms was nullptr.

Call Stack:

Code: Select all

>	xul.dll!nsScriptLoader::InstantiateModuleTree(nsModuleLoadRequest * aRequest) Line 1147	C++
 	xul.dll!nsModuleLoadRequest::DependenciesLoaded() Line 275	C++
 	xul.dll!mozilla::MozPromise<bool,enum nsresult,0>::MethodThenValue<nsModuleLoadRequest,void (__cdecl nsModuleLoadRequest::*)(void) __ptr64,void (__cdecl nsModuleLoadRequest::*)(void) __ptr64>::DoResolveOrRejectInternal(const mozilla::MozPromise<bool,enum nsresult,0>::ResolveOrRejectValue & aValue) Line 546	C++
 	xul.dll!mozilla::MozPromise<nsTArray<bool>,enum nsresult,0>::ThenValueBase::DoResolveOrReject(const mozilla::MozPromise<nsTArray<bool>,enum nsresult,0>::ResolveOrRejectValue & aValue) Line 433	C++
 	xul.dll!mozilla::MozPromise<nsTArray<bool>,enum nsresult,0>::ThenValueBase::ResolveOrRejectRunnable::Run() Line 338	C++
 	xul.dll!mozilla::AutoTaskDispatcher::TaskGroupRunnable::Run() Line 196	C++
 	xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool * aResult) Line 1147	C++
 	xul.dll!NS_ProcessNextEvent(nsIThread * aThread, bool aMayWait) Line 356	C++
 	xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate) Line 96	C++
 	xul.dll!MessageLoop::Run() Line 206	C++
 	xul.dll!nsBaseAppShell::Run() Line 155	C++
 	xul.dll!nsAppShell::Run() Line 264	C++
 	xul.dll!nsAppStartup::Run() Line 284	C++
 	xul.dll!XREMain::XRE_mainRun() Line 3860	C++
 	xul.dll!XREMain::XRE_main(int argc, char * * argv, const nsXREAppData * aAppData) Line 3989	C++
 	xul.dll!XRE_main(int argc, char * * argv, const nsXREAppData * aAppData, unsigned int aFlags) Line 4071	C++
 	palemoon.exe!do_main(int argc, char * * argv, char * * envp, nsIFile * xreDirectory) Line 255	C++
 	palemoon.exe!NS_internal_main(int argc, char * * argv, char * * envp) Line 379	C++
 	palemoon.exe!wmain(int argc, wchar_t * * argv) Line 114	C++
 	[External Code]	

Minidump: http://repository.binaryoutcast.com/artifacts/dumps/palemoon-20200225-4ff7606b6-lacoste.com.7z

[New Tobin Paradigm]

A null check, of course, will bypass the crash and there IS a bugzilla bug associated that seems to describe this but wasn't very detailed and no one followed up until much later when it was RESOLVED WORKSFORME likely due to refactoring fixing this likely piss poor eager instantiation bullshit that landed in gecko/51.. But that doesn't solve the core issue. I tried a few fixes that SEEMED related but they didn't help either. Also, even if it doesn't crash the site is horribly busted because it is obviously expecting a fully to-spec + whatever bullshit behavior was changed later implementation.

I have exhausted my skill set here. Have fun, whomever takes a stab at it who is likely named Moonchild.

Also, someone file an issue at the UXP repo, I'm going to bed.

[Moonchild]

Even if it looks like shit we shouldn't be crashing because of content.
Also a crash dump "from tip" won't be usable because I won't have the symbols of that particular build.

[New Tobin Paradigm]

Oh yeah, symbols. I forgot. Gimmy a few to wake up.

[Moonchild]

For the record, the cause has been found and a new version will be released to address this crash.

[New Tobin Paradigm]

Do note, as I said, this will not make the site fully functional.. It just won't crash anymore. ES Modules are on the agenda but it will not be completed by the new Milestone's first release.