Browser getting white after navigation and some SPA actions

[Phylanx]

Hi!

First our environment:

Windows 11, 64bit
JDK8, 32 bit
JCEF cffac273e4f90348ee02a29ffd919388432fce9f, CEF 143.0.14+gdd46a37+chromium-143.0.7499.193

Our usecase:
After doing some actions on a page the following errors occur:
The browser itself goes white and the following error logging comes after some time:

Code: Select all

[12348:6252:0429/115205.422:ERROR:cef\libcef\browser\browser_info_manager.cc:850] Timeout of new browser info response for frame C-F314F6C746BF4AE3562752D641374D82 (has_rfh=1)


I already checked the issue referenced in https://www.magpcss.org/ceforum/viewtop ... =6&t=20361.
The fix is already active but the bug reproduces anyway.
We also found the following logging:

Code: Select all

[16192:3280:0429/115058.245:ERROR:third_party\blink\renderer\bindings\core\v8\v8_initializer.cc:852] V8 javascript OOM (Reached heap limit).


and if we open DevTools, the DevTools automatically closes and the following error is logged:

Code: Select all

[12348:6252:0429/115050.361:ERROR:CONSOLE:1] "console.assert", source: devtools://devtools/bundled/entrypoints/formatter_worker/formatter_worker.js (1)


When we're opening the same page with firefox, chrome or edge it works.
The problem can be reproduced in our integration, our minimal integration and also when using the detailed MainFrame.

Anybody knows where to look at?

[magreenblatt]

I don't think you need to look any further than:

> JDK8, 32 bit

[Phylanx]

@Marshall: Thx for your answer.
Unfortunately that doesn't help us with our problem.
We're aware of our technical debt with JDK8 and explicitly with 32bit architecture but we have a whole big legacy application with dependencies on 32bit in the background.
I would love to upgrade to 64 bit as I see all the problems we have with our current architecture, but we have too few people doing too much work in too short time.
Reality is a b****.

Can you hint something to us where to look at to find a practical working solution?
Additional logging, profiling,... we can turn on?

[magreenblatt]

[16192:3280:0429/115058.245:ERROR:third_party\blink\renderer\bindings\core\v8\v8_initializer.cc:852] V8 javascript OOM (Reached heap limit).

This memory issue is in the renderer process, so at least the JVM memory pressure isn't contributing to the problem. If you're using the standard JCEF build configuration then it should already have all appropriate build flags (/LARGEADDRESSAWARE, /STACK:0x80000, etc). I'm not aware of anything else to be done, beyond switching to 64-bit processes.

[Phylanx]

ok, thanks so far!
I'll try to investigate more.

The problem occurs only on a specific feature of the SPA, meaning that it might depend on some special functionality only used there.
I'll try investigating more in this direction.
Will be difficult without DevTools though

[Phylanx]

I just checked the two flags you mentioned earlier (/LARGEADDRESSAWARE, /STACK:0x80000).
Where do they have to be set? I only found them specifically set in the VS Project properties of the jcef_helper.exe.
the jcef project does not specifically set them. Might this be a problem?

[magreenblatt]

I only found them specifically set in the VS Project properties of the jcef_helper.exe.

That is correct, they're exe properties.

[Phylanx]

After some additional analysis we found out that one of the renderer subprocesses crashes.
It might have to do something with the previously mentioned OOM logging...

Further analysis ongoing...

[ndesktop]

After some additional analysis we found out that one of the renderer subprocesses crashes.
It might have to do something with the previously mentioned OOM logging...

Further analysis ongoing...

When the browser "goes white" this is the usual culprit. I am seeing OOMs lately on 32-bit as well (in a C++ native app); I'm not sure this is about Java 32-bit, but rather more about the 32-bit itself.

[Phylanx]

When trying to reproduce the problem with detailed MainFrame, we get the following output in the console:

Code: Select all

render process terminated: TS_PROCESS_CRASHED errorCode: -1073741571 errorString: STATUS_STACK_OVERFLOW


Meaning the renderer process crashed with a "STATUS_STACK_OVERFLOW " error.

We didn't see it before because it is not written into the file logs.

We also found out that the problem does not reproduce with the cefclient.exe we took from our same 32bit build as our self built libcef.dll.
That means it has to be something in the JCEF layer of the application as it is reproducable with detailed/simple MainFrame but not with cefclient.