[External] : Re: OpenJFX custom build - Java application crash (semi-related to 8262276)

Mon Apr 12 07:59:21 UTC 2021

Did the thread dump created using the debug build helped with understanding
of what the issue was?

— PrimosK

On Tue, 23 Mar 2021 at 18:53, Arun Joseph <arun.aj.joseph at oracle.com> wrote:

> The thread dump doesn’t have enough details to locate where the problem
> occurs. Using a debug build with assertions disabled (as mentioned in the
> previous mail) may help in generating a thread dump for getting some more
> information.
>
> — Arun Joseph
>
> On 18-Mar-2021, at 3:39 PM, Primož Kokol <primoz.kokol at gmail.com> wrote:
>
> Thanks for pointing us in the right direction. I wasn't aware that
> jfxwebkit.pdb will be
> generated also in the case of a production build.
>
> So after generating a production build we were able to produce a thread
> dump  (using
> jfxwebkit.pdb symbols) at the time when the application freezes. The
> complete bug report
> including thread dump is there:
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263788
> <https://urldefense.com/v3/__https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263788__;!!GqivPVa7Brio!PNGdt-6i1OVlO2wDGTAtrKqpYpUwAwVhSlCnjD5ZDMFBKT5TzscS2TxfNzhFNz_rHv8-$>
>
> Could you please just scan through it and let us know whether there is
> enough information
> to pursue this further or whether any additional information is needed?
>
> — PrimosK
>
> On Tue, 16 Mar 2021 at 13:30, Arun Joseph <arun.aj.joseph at oracle.com>
> wrote:
>
>> The app is now crashing at InternalFunction which calls jsDynamicCast in
>> JSCast.h, which lead to the initial crash. This assert failure occurs
>> because the type value is ObjectType instead of InternalFunctionType
>> or NullSetterFunctionType. I need to check why this is happens.
>>
>> NDEBUG and ASSERT_ENABLED are used interchangeably in the WebKit code.
>> So, for creating a build without asserts, you can either use the release
>> build PDBs, or set NDEBUG to 1 in WTF/wtf/PlatformEnable.h to generate a
>> minimal debug build.
>>
>> — Arun Joseph
>>
>> On 15-Mar-2021, at 6:08 PM, Primož Kokol <primoz.kokol at gmail.com> wrote:
>>
>> I've tried to remove this particular assert statement at "JSCast.h:143":
>> // ASSERT_UNUSED(vm, canCast == from->JSCell::inherits(vm,
>> Target::info()));
>>
>> ... and now application crashes at different assert statement:
>>
>> > jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal,
>> const char * __formal, int __formal) Line 672 C++ Symbols loaded.
>>   jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, const
>> WTF::String & name, JSC::InternalFunction::NameAdditionMode
>> nameAdditionMode) Line 49 C++ Symbols loaded.
>>   jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const
>> WTF::String & ident) Line 58 C++ Symbols loaded.
>>   jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData,
>> const WTF::String & name) Line 231 C++ Symbols loaded.
>>   jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject *
>> globalObject, const WTF::String & name, JSC::Bindings::Method * method)
>> Line 212 C++ Symbols loaded.
>>
>> jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject *
>> globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols loaded.
>>
>> jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject
>> * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName)
>> Line 124 C++ Symbols loaded.
>>   jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject *
>> globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded.
>>   jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject *
>> globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols loaded.
>>   jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject,
>> JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++
>> Symbols loaded.
>>   jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction *
>> pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject,
>> JSC::JSValue baseValue, const JSC::Identifier & ident,
>> JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded.
>>   jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame,
>> const JSC::Instruction * pc) Line 833 C++ Symbols loaded.
>>   jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded.
>>   00000025dabfaf00() Unknown Non-user code
>>   00000025dabfafc0() Unknown Non-user code
>>   00000164ca445b4b() Unknown Non-user code
>>   cccccccccccccccc() Unknown Non-user code
>>   00000164ca445b46() Unknown Non-user code
>>
>> Is there any way we could turn off assertions in general when producing
>> debug build?
>>
>> On Sat, 13 Mar 2021 at 05:41, Arun Joseph <arun.aj.joseph at oracle.com>
>> wrote:
>>
>>> I’m currently looking into why the native debug build is crashing. This
>>> same assert fails while running FileReaderTest using the native debug
>>> build. For the time being, you can try building by removing this particular
>>> assert statement for debugging.
>>>
>>> — Arun Joseph
>>>
>>> > On 12-Mar-2021, at 11:47 PM, Primož Kokol <primoz.kokol at gmail.com>
>>> wrote:
>>> >
>>> > Hi Kevin,
>>> >
>>> > Unfortunately I don't have a test case. We are using various WebViews
>>> in
>>> > our production application hence we don't know where/why exactly the
>>> > application freezes.
>>> >
>>> > We were hoping that we will be able to identify it using the native
>>> debug
>>> > build (& attached debugged) but it is now unfortunately crashing with
>>> the
>>> > above error.
>>> >
>>> > Side note:
>>> > Should I contact Arun directly or is he seeing these messages?
>>> >
>>> > -- PrimosK
>>> >
>>> > On Fri, 12 Mar 2021 at 19:00, Kevin Rushforth <
>>> kevin.rushforth at oracle.com>
>>> > wrote:
>>> >
>>> >> Arun should be able to help you with the crash you are seeing in debug
>>> >> mode.
>>> >>
>>> >> Regarding the hang, do you have a test case that will reproduce it? A
>>> >> few different developers have reported similar hangs. We ended up
>>> >> closing a recently-filed bug, JDK-8260238 [1], because were (and still
>>> >> are) unable to reproduce the hang.
>>> >>
>>> >> -- Kevin
>>> >>
>>> >> [1] https://bugs.openjdk.java.net/browse/JDK-8260238
>>> >>
>>> >>
>>> >> On 3/12/2021 1:06 AM, Primož Kokol wrote:
>>> >>> Hi everyone,
>>> >>>
>>> >>> I would need some help related to OpenJFX build.
>>> >>>
>>> >>> I was able to successfully prepare a build following this procedure
>>> (from
>>> >>> pull/417 request):
>>> >>> https://github.com/openjdk/jfx/pull/417#issuecomment-795178731
>>> <https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/417*issuecomment-795178731__;Iw!!GqivPVa7Brio!Lu8MhGsAzeidNANqG0a0sCdMXLnMmT0YMF8vL7Z3VX_HYg2sglHpvMA9Vxw2b72f-2Uo$>
>>> >>>
>>> >>> We wanted to use it in our existing application (Java 11.0.10) to
>>> debug
>>> >> an
>>> >>> issue where the application would hang/freeze for no obvious reason
>>> >> because
>>> >>> of WebKit.
>>> >>>
>>> >>> In order to use this build we've manually overridden javafx-*.jar
>>> files
>>> >> in
>>> >>> our application with the ones from the above build.
>>> >>> We've also placed all produced DLL files in our application's "bin"
>>> >> folder
>>> >>> so they are properly picked up (I've verified and I can confirm that
>>> >>> jfxwebkit.dll produced by our debug build is loaded).
>>> >>>
>>> >>> After using this native debug build, the application will crash
>>> instead
>>> >>> with:
>>> >>> Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe:
>>> >> Fatal
>>> >>> program exit requested.
>>> >>>
>>> >>> It looks like it happens when JS code calls Java method.
>>> >>>
>>> >>> There is the call stack at the time when exception happens:
>>> >>>
>>> >>>> ucrtbase.dll!abort () Unknown Non-user code. Symbols loaded.
>>> >>>   jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal,
>>> >> const
>>> >>> char * __formal, int __formal) Line 672 C++ Symbols loaded.
>>> >>>
>>> >>>
>>> >>
>>> jfxwebkit.dll!JSC::JSCastingHelpers::inheritsJSTypeImpl<JSC::InternalFunction,JSC::InternalFunction>(JSC::VM
>>> >>> & vm, JSC::InternalFunction * from, JSC::JSTypeRange range) Line 143
>>> C++
>>> >>> Symbols loaded.
>>> >>>
>>> >>>
>>> >>
>>> jfxwebkit.dll!JSC::JSCastingHelpers::InheritsTraits<JSC::InternalFunction>::inherits<JSC::InternalFunction>(JSC::VM
>>> >>> & vm, JSC::InternalFunction * from) Line 164 C++ Symbols loaded.
>>> >>>   jfxwebkit.dll!JSC::jsDynamicCast<JSC::InternalFunction
>>> >>> *,JSC::InternalFunction>(JSC::VM & vm, JSC::InternalFunction * from)
>>> Line
>>> >>> 182 C++ Symbols loaded.
>>> >>>   jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm,
>>> >> const
>>> >>> WTF::String & name, JSC::InternalFunction::NameAdditionMode
>>> >>> nameAdditionMode) Line 49 C++ Symbols loaded.
>>> >>>   jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm,
>>> const
>>> >>> WTF::String & ident) Line 58 C++ Symbols loaded.
>>> >>>   jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM &
>>> globalData,
>>> >>> const WTF::String & name) Line 231 C++ Symbols loaded.
>>> >>>   jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject *
>>> >>> globalObject, const WTF::String & name, JSC::Bindings::Method *
>>> method)
>>> >>> Line 212 C++ Symbols loaded.
>>> >>>
>>> >>
>>> jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject
>>> >>> * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols
>>> >> loaded.
>>> >>>
>>> >>>
>>> >>
>>> jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject
>>> >>> * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName
>>> propertyName)
>>> >>> Line 124 C++ Symbols loaded.
>>> >>>   jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject *
>>> >>> globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols
>>> loaded.
>>> >>>   jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject *
>>> >>> globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols
>>> >> loaded.
>>> >>>   jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject,
>>> >>> JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963
>>> C++
>>> >>> Symbols loaded.
>>> >>>   jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const
>>> JSC::Instruction *
>>> >>> pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject,
>>> >>> JSC::JSValue baseValue, const JSC::Identifier & ident,
>>> >>> JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded.
>>> >>>   jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame,
>>> >> const
>>> >>> JSC::Instruction * pc) Line 833 C++ Symbols loaded.
>>> >>>   jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded.
>>> >>>   000000c7ef8fae90() Unknown Non-user code
>>> >>>   000000c7ef8faf50() Unknown Non-user code
>>> >>>   0000028d52eeedbb() Unknown Non-user code
>>> >>>   cccccccccccccccc() Unknown Non-user code
>>> >>>   0000028d52eeedb6() Unknown Non-user code
>>> >>>
>>> >>> ... and partial output from the output console:
>>> >>>
>>> >>> ....
>>> >>> (S)tacking Context/(F)orced SC/O(P)portunistic SC, (N)ormal flow
>>> only,
>>> >>> (O)verflow clip, (A)lpha (opacity or mask), has (B)lend mode,
>>> (I)solates
>>> >>> blending, (T)ransform-ish, (F)ilter, Fi(X)ed position, Behaves as
>>> >> fi(x)ed,
>>> >>> (C)omposited, (P)rovides backing/uses (p)rovided backing/paints to
>>> >>> (a)ncestor, (c)omposited descendant, (s)scrolling ancestor,
>>> >> (t)transformed
>>> >>> ancestor
>>> >>> Dirty (z)-lists, Dirty (n)ormal flow lists
>>> >>> Traversal needs: requirements (t)raversal on descendants, (b)acking
>>> or
>>> >>> hierarchy traversal on descendants, (r)equirements traversal on all
>>> >>> descendants, requirements traversal on all (s)ubsequent layers,
>>> >> (h)ierarchy
>>> >>> traversal on all descendants, update of paint (o)rder children
>>> >>> Update needs:    post-(l)ayout requirements, (g)eometry, (k)ids
>>> geometry,
>>> >>> (c)onfig, layer conne(x)ion, (s)crolling tree
>>> >>> Scrolling scope: box contents
>>> >>>
>>> >>> S-------------- -- ------ -----s 34 34 0000028D98F22260 (0,0)
>>> width=460
>>> >>> height=650 RenderView 0x28d4d4d1cd0
>>> >>> S-------------- -- ------ ------ 34 34   + 0000028D4D98D430 (0,0)
>>> width=
>>> >> no
>>> >>> compositing work to do
>>> >>> FrameView 0000028D4F2A4CF0 performPostLayoutTasks
>>> >>>
>>> >>> FrameView 0000028D4F2A4CF0 updateLayoutViewport() totalContentSize
>>> >>> width=460 height=650 unscaledDocumentRect (0,0) width=460 height=650
>>> >> header
>>> >>> height 0 footer height 0 fixed behavior 0
>>> >>> layoutViewport: (0,0) width=460 height=650
>>> >>> visualViewport: (0,0) width=460 height=650 (is override 0)
>>> >>> stable origins: min: (0.00,0.00) max: (0.00,0.00)
>>> >>> DocumentTimelinesController::updateAnimationsAndSendEvents for time
>>> >> 24.89s
>>> >>> DeclarativeAnimation::tick for element node 0000028D40C406A0 DIV
>>> >>> 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated'
>>> >>> KeyframeEffect::invalidate on element node 0000028D40C406A0 DIV
>>> >>> 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated'
>>> >>> DeclarativeAnimation::tick for element node 0000028D40C42E90 DIV
>>> >>> 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated'
>>> >>> KeyframeEffect::invalidate on element node 0000028D40C42E90 DIV
>>> >>> 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated'
>>> >>> EventDispatcher::dispatchEvent transitioncancel on node DIV
>>> >>> EventDispatcher::dispatchEvent transitioncancel on node DIV
>>> >>> ASSERTION FAILED: canCast == from->JSCell::inherits(vm,
>>> Target::info())
>>> >>>
>>> >>
>>> C:\jfx\modules\javafx.web\src\main\native\Source\JavaScriptCore\runtime\JSCast.h(143)
>>> >>> : JSC::JSCastingHelpers::inheritsJSTypeImpl
>>> >>> Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe:
>>> >> Fatal
>>> >>> program exit requested.
>>> >>>
>>> >>> Note that this crash isn't happening with official JavaFX 15, 16, and
>>> >>> 17-ea+2 builds (that are at the time of writing this available on the
>>> >>> maven), but unfortunately we can't use these for debugging purposes.
>>> >>>
>>> >>> Does that indicate any issues with the native debug build or is this
>>> some
>>> >>> regression that was introduced in the current `master` branch
>>> recently
>>> >>> (after 17-ea+2)?
>>> >>>
>>> >>> Thanks for any helpful hints/advice in advance!
>>> >>>
>>> >>> Best regards,
>>> >>> PrimosK
>>> >>
>>> >>
>>>
>>>
>>
>