Doesn't work VK.com (crashed)

[Moonchild]

Not sure what you are asking. If you're asking us to use V8/Blink, then the answer is "no". If you're asking us to work on solving web compatibilities by implementing new things Chrome introduces, then the answer is "what do you think we've been doing for years now?" (i.e.: yes, we're working on it).

A browser not rendering the page correctly is somewhat different from browser that is easy to crash unintentionally with ordinary web content. The first problem is reasonably explained by the websites not following the standards, the second one is purely browser-caused.

You're absolutely right in that - which is why crashes tend to get higher priority; the issue here is that analysing WHY it crashes is made extremely difficult because of the site's apparent abuse of some of the most complex specifications (from an implementation perspective) out there. Indirectly it's caused by draft "standards" causing this needed complexity in a browser and making it less stable due to the need for asynchronous operations everywhere. Sure, we could avoid potential crashes by simply not implementing it, but then we'd be standing still and having a lot more websites simply not work.

As for this particular crash, I'm not sure where to even begin - the call stacks are all over the place meaning it's something timing-related and it's not clear at this point which of the millions of bytes of minified JS is triggering it. While we try to figure that out, your workaround would be to use a different browser in the interim.

ordinary web content

One can ask oneself if what vk does is "ordinary web content" - I'd say it isn't.

[pvgoran]

I was just hit by this issue. Spent half a day upgrading the browser, disabling extensions one by one and things like this, only to find out that vk.com crashes PaleMoon even in a fresh profile, with all plug-ins disabled, without login, and even in safe mode.

Some additional information, which may or may not be useful: depending on enabled extensions, the browser can crash on the first attempt to open the site (at least with a login), or on subsequent attempts (close tab - open new tab - open vk.com - repeat if no crash). In any case, I can reliably trigger a crash by repeatedly closing the tab and re-opening vk.com in a new tab, all within the same browsing session (without clearing cache and such), usually within 2-3 cycles.

[moonbat]

Confirmed - VK crashes on Linux on the blank profile I keep for website testing. Froze the browser window for several seconds, after which it disappeared.

[dbsoft]

Try disabling WebAssembly (WASM) under Preferences -> Content -> General -> JavaScript

(Might require a restart after disabling)

[_yuyu_]

Try disabling WebAssembly (WASM) under Preferences -> Content -> General -> JavaScript

It worked.
PS. No... After restarting the browser it still crashes.

[dbsoft]

Ok, it is near some special case for WASM and I wasn't able to reproduce with WASM off and on ARM which doesn't support WASM. I'll try to look into it later tonight.

Edit: Looks like it is a use after free: Address Sanitizer Error: Use of deallocated memory

Code: Select all

    js::Scope* getScope(size_t index) const {
        js::ScopeArray* array = scopes();
        MOZ_ASSERT(index < array->length);
>       return array->vector[index];
    }

Code: Select all

[External Code]
mozjs.dll!JSScript::getScope(unsigned __int64 index) Line 1893
	at c:\Work\PaleMoon\White-Star\platform\js\src\jsscript.h(1893)
mozjs.dll!JSScript::bodyScope() Line 1706
	at c:\Work\PaleMoon\White-Star\platform\js\src\jsscript.h(1706)
mozjs.dll!JSScript::functionNonDelazifying() Line 1618
	at c:\Work\PaleMoon\White-Star\platform\js\src\jsscript.h(1618)
mozjs.dll!js::InterpreterFrame::isFunctionFrame() Line 445
	at c:\Work\PaleMoon\White-Star\platform\js\src\vm\Stack.h(445)
mozjs.dll!js::InterpreterFrame::hasArgs() Line 501
	at c:\Work\PaleMoon\White-Star\platform\js\src\vm\Stack.h(501)
mozjs.dll!js::InterpreterFrame::trace(JSTracer * trc, JS::Value * sp, unsigned char * pc) Line 366
	at c:\Work\PaleMoon\White-Star\platform\js\src\vm\Stack.cpp(366)
mozjs.dll!MarkInterpreterActivation(JSTracer * trc, js::InterpreterActivation * act) Line 419
	at c:\Work\PaleMoon\White-Star\platform\js\src\vm\Stack.cpp(419)
mozjs.dll!js::MarkInterpreterActivations(JSRuntime * rt, JSTracer * trc) Line 429
	at c:\Work\PaleMoon\White-Star\platform\js\src\vm\Stack.cpp(429)
mozjs.dll!js::gc::GCRuntime::traceRuntimeCommon(JSTracer * trc, js::gc::GCRuntime::TraceOrMarkRuntime traceOrMark, js::AutoLockForExclusiveAccess & lock) Line 330
	at c:\Work\PaleMoon\White-Star\platform\js\src\gc\RootMarking.cpp(330)
mozjs.dll!js::gc::GCRuntime::traceRuntimeForMinorGC(JSTracer * trc, js::AutoLockForExclusiveAccess & lock) Line 285
	at c:\Work\PaleMoon\White-Star\platform\js\src\gc\RootMarking.cpp(285)
mozjs.dll!js::Nursery::doCollection(JSRuntime * rt, JS::gcreason::Reason reason, js::gc::TenureCountCache & tenureCounts) Line 634
	at c:\Work\PaleMoon\White-Star\platform\js\src\gc\Nursery.cpp(634)
mozjs.dll!js::Nursery::collect(JSRuntime * rt, JS::gcreason::Reason reason) Line 524
	at c:\Work\PaleMoon\White-Star\platform\js\src\gc\Nursery.cpp(524)
mozjs.dll!js::gc::GCRuntime::minorGC(JS::gcreason::Reason reason, js::gcstats::Phase phase) Line 6084
	at c:\Work\PaleMoon\White-Star\platform\js\src\jsgc.cpp(6084)
mozjs.dll!js::gc::GCRuntime::gcIfRequested() Line 6122
	at c:\Work\PaleMoon\White-Star\platform\js\src\jsgc.cpp(6122)
mozjs.dll!InvokeInterruptCallback(JSContext * cx) Line 527
	at c:\Work\PaleMoon\White-Star\platform\js\src\vm\Runtime.cpp(527)
mozjs.dll!JSRuntime::handleInterrupt(JSContext * cx) Line 615
	at c:\Work\PaleMoon\White-Star\platform\js\src\vm\Runtime.cpp(615)
mozjs.dll!js::CheckForInterrupt(JSContext * cx) Line 746
	at c:\Work\PaleMoon\White-Star\platform\js\src\jscntxt.h(746)
mozjs.dll!js::jit::InterruptCheck(JSContext * cx) Line 459
	at c:\Work\PaleMoon\White-Star\platform\js\src\jit\VMFunctions.cpp(459)
[External Code]

[Enobarbous]

I doubt this will be useful, but just in case....
For some reason, I used the old version of PM and noticed that it did not crash.
I did a little digging - the latest version of PM, which does not crash on vk.com, is 32.1.1, with 32.2 crashes begin.
To narrow the question somewhat, I used roytam1 builds (yes, I know that this is not an off PM, but in this case the behavior is the same) - tests showed that crashes start with git-20230506, in the previous build (20230415) there were none.
In all cases, tests were carried out on win7 x64 versions

[Moonchild]

Unfortunately it doesn't help because there was a massive amount of code included related to dynamic module imports between those builds. So the issue would be "somewhere in or related to dynamic module imports" which doesn't narrow it down.

[Enobarbous]

I thought about it, but after spending a couple of hours testing the idea, I decided to write the result.
After that I thought that javascript.options.dynamicImport = false would help against crashes, but it didn't work out that way

[yury_700]

Bump.
So is there any hope regarding this issue? PM 33.3.1 has it too, with blank or non-blank profile. Weirdly sometimes it may succeed in loading vk.com once or twice, either directly or by a reference (but ultimately I get a crash).
The addons composition seems to have some influence but isn't a decisive factor. E.g. switching off Tab Mix Plus seems to help a bit. And the mobile version of the site works (well, it never stops 'spinning the wheel' but hey).
Noob's suggestion: is it some weird timing issue?
FWIW, the latest Seamonkey also crashes on the first button click on vk.com's register screen, only it's backtrace in libxul.so is like 70+ entries long. PM's backtrace looks like the snip that ends this comment.

Does it look like a solvable issue?

#0 0x00007ffff5e00da3 in ??? () at /home/me/p/palemoon/libxul.so
#1 0x00007ffff5e0461c in ??? () at /home/me/p/palemoon/libxul.so
#2 0x00007ffff5f79b83 in ??? () at /home/me/p/palemoon/libxul.so
#3 0x00007ffff5f7a2f8 in ??? () at /home/me/p/palemoon/libxul.so
#4 0x00007ffff5f7cf43 in ??? () at /home/me/p/palemoon/libxul.so
#5 0x00007ffff5c874ea in ??? () at /home/me/p/palemoon/libxul.so
#6 0x00007ffff5cb2239 in ??? () at /home/me/p/palemoon/libxul.so
#7 0x00007ffff5f5b3f5 in ??? () at /home/me/p/palemoon/libxul.so
#8 0x00007ffff5f63f8d in ??? () at /home/me/p/palemoon/libxul.so
#9 0x00007ffff5e091ed in ??? () at /home/me/p/palemoon/libxul.so
#10 0x00007ffff5e0eccb in ??? () at /home/me/p/palemoon/libxul.so
#11 0x00007ffff5e0fd62 in ??? () at /home/me/p/palemoon/libxul.so
#12 0x00007ffff5db6a04 in ??? () at /home/me/p/palemoon/libxul.so
#13 0x00007ffff5dcf786 in ??? () at /home/me/p/palemoon/libxul.so
#14 0x00007ffff5c909ad in ??? () at /home/me/p/palemoon/libxul.so
#15 0x00007ffff59d66e9 in ??? () at /home/me/p/palemoon/libxul.so
#16 0x000035bd1376491a in ??? ()
#17 0x00007fffe7f17e38 in ??? ()
#18 0x00007ffffffef550 in ??? ()
#19 0x0000000000000000 in ??? ()

[adoxa]

If it's suitable m.vk.com seems to work (at least, I got to the sign up page).

[yury_700]

If it's suitable m.vk.com seems to work (at least, I got to the sign up page).

Yeah, it does. Like I've said,

And the mobile version of the site works (well, it never stops 'spinning the wheel' but hey).

Only it's a bit substandard when on a big display. Also one still needs to avoid external links into vk.com (and shortcutting vk.com to m.vk.com through hosts file works only partially).

[adoxa]

Yeah, [mobile] does.

Ah, sorry, I thought mobile was mentioned, but I searched for "m.vk", not "mobile".

Also one still needs to avoid external links into vk.com [...]

URL Rewriter could probably take care of that.

[yury_700]

URL Rewriter could probably take care of that.

Weeell, it could if it'd worked as advertised. I've just spent like half an hour with the thing. Had to go with the wildcard version of the rule because the regex version seems buggy.
One rather simple regexp, how difficult could it be?

Code: Select all

(https?://)?vk.com(/.*)?
$1m.vk.com$2

But no. First, the rule doesn't work (no match? no action?). And then - get it! - it auto-disables itself.
The only positive result I'm observing is it seems like that small additional delay throws off that timing(?) issue and I get a page instead of a crash. Won't put my money on that, it just seems to look that way.

Maybe this info'd help somehow with the issue.

[frostknight]

No problems for me on going on that website, unless logging in is what you meant.

I am using an unbranded 33.3.1 palemoon currently btw.

[yury_700]

...also, after the opening of anything on vk.com with no subsequent crash, PM stays at high CPU load and high-ish memory consumption even with no pages open (I've seen numbers up to 70% CPU and c. 10% memory), as if something like 'zombie processes' were left in memory.
Same goes for youtube.com videos, BTW.

[adoxa]

Code: Select all

(https?://)?vk.com(/.*)?
$1m.vk.com$2

But no. First, the rule doesn't work (no match? no action?). And then - get it! - it auto-disables itself.

Testing it results in an error: "The example url https://vk.com/some/path matches the redirect and would redirect you to https://m.vk.com/some/path, which also matches the redirect. This is not allowed as it can cause an endless loop of requests." Just adding the start anchor is enough: ^(http....

[yury_700]

Just adding the start anchor is enough: ^(http....

Thank you for going out and checking, I was wondering about that, but was out of time and had had wildcard version working already.
Now that load problem comes to fore. I'm watching youtube in new firefox for years because of that, and now (m.)?vk.com has the problem too.