tdlib Java example on Windows: fatal error on the latest build (f013f47) about td

[levlam]

With all the details it now looks like an MSVC 19.40.33811.0 bug. Some other MSVC users have similar issue in other projects, for example, https://developercommunity.visualstudio.com/t/Invalid-code-generation-in-release-1940/10678572. I would suggest to downgrade MSVC if possible, or wait for the issue to be investigated by MSVC team and use the working dll in the meanwhile.

[levlam]

The example works correctly for me with Java HotSpot(TM) 64-Bit Server VM (build 20.0.1+9-29, mixed mode, sharing).

For you it crashes on the first native call to tdjni.dll as if it was built for incompatible JVM. Do you have only OpenJDK installed, or there is also HotSpot?

[andreymerchenko]

I tried to build tdlib using jdk 17 (openjdk 17.0.2+8-86) and jdk 21 (openjdk 21.0.1+12-29). For jdk 21 also got the same error:

C:\app\jdk-21.0.1\bin\java.exe -javaagent:C:\app\Idea\lib\idea_rt.jar=56395:C:\app\Idea\bin -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.stderr.encoding=UTF-8 -classpath C:\tdlib\example\out\production\example org.drinkless.tdlib.example.Example
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff83b0532a8, pid=14868, tid=5888
#
# JRE version: OpenJDK Runtime Environment (21.0.1+12) (build 21.0.1+12-29)
# Java VM: OpenJDK 64-Bit Server VM (21.0.1+12-29, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# C [msvcp140.dll+0x132a8]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\tdlib\example\hs_err_pid14868.log
#
# If you would like to submit a bug report, please visit:
# https://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

[levlam]

Could you try to run the example manually from console:

cd <path to tdjni.dll>
java '-Djava.library.path=.' org/drinkless/tdlib/example/Example

?

[andreymerchenko]

Here is the command output:

c:\tdlib21\td\tdlib\bin>cd c:\tdlib21\td\tdlib\bin

c:\tdlib21\td\tdlib\bin>java -version
openjdk version "21.0.1" 2023-10-17
OpenJDK Runtime Environment (build 21.0.1+12-29)
OpenJDK 64-Bit Server VM (build 21.0.1+12-29, mixed mode, sharing)

c:\tdlib21\td\tdlib\bin>java -Djava.library.path=. org/drinkless/tdlib/example/Example
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd9bd332a8, pid=14304, tid=2992
#
# JRE version: OpenJDK Runtime Environment (21.0.1+12) (build 21.0.1+12-29)
# Java VM: OpenJDK 64-Bit Server VM (21.0.1+12-29, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# C [msvcp140.dll+0x132a8]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# c:\tdlib21\td\tdlib\bin\hs_err_pid14304.log
#
# If you would like to submit a bug report, please visit:
# https://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

c:\tdlib21\td\tdlib\bin>

[levlam]

Could you try with have just pushed commit?

[andreymerchenko]

Hi levlam, thank you very much for being willing to help!

I tried with the latest pushed commit and still having this issue. The build is properly built for my colleague (at least on jdk 17) and his dlls work for me, the build outputs are pretty much the same. This looks like some local issue specific to my env and related to how the dlls are built.

I tried different versions of CMake: 3.29.4 and 3.27.1.

Here is the output of the build commands: log.txt. Maybe it will give some hints why the built dlls are causing fatal error on Java application start.

Thanks.

[levlam]

The log contains no errors. The library was built successfully and is of the latest version available. Could you check that you use C:/tdlib/td/tdlib/bin/tdjni.dll and not an older version?

[andreymerchenko]

Hi levlam, thank you for checking the logs and confirming that no issues are there.
Yes, the newly generated tdjni.dll is used as I am using the following commands to check if example works:

cd <path to tdjni.dll>
java '-Djava.library.path=.' org/drinkless/tdlib/example/Example

where <path to tdjni.dll> is the newly generated path during the build.

Thank you.

[levlam]

This looks like some local issue specific to my env and related to how the dlls are built.

Despite possible, it is highly unlikely that the issue is caused by a bug in toolchain, for example, in MSVC. It is hard to guess what could be the actual cause, given everything works correctly for me with the latest commit.

Could you try to build a Debug version of TDLib and tdjni.dll and check whether it crashes differently?

[levlam]

You can also try to enable TDLib log with verbosity level 10 by changing the line Client.execute(new TdApi.SetLogVerbosityLevel(0)); and rebuilding the example. TDLib may be able to print something in the log before the crash.

[andreymerchenko]

Hello, levlam, sorry for the delay and thanks for the suggestions!

Setting logVerbosityLevel did not reveal any changes in the error output.

It's interesting that the debug version of the build works (--config Debug).

I tried to reinstall MS Visual Studio and CMake several times, it did not work.

Still facing the fatal error issue with running example with dlls built on my machine (when using --config Release). For the dlls built by my colleague example app works.

Thanks again for the ideas and suggestions!

[levlam]

What's your MSVC version and your colleague's MSVC version?

[andreymerchenko]

For me:

-- Building for: Visual Studio 17 2022
-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.22631.
-- The CXX compiler identification is MSVC 19.40.33811.0
-- The C compiler identification is MSVC 19.40.33811.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: D:/Program Files/MicrosoftVisualStudio/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64/cl.exe - skipped

For colleague:

-- Building for: Visual Studio 17 2022
-- Selecting Windows SDK version 10.0.22000.0 to target Windows 10.0.19045.
-- The CXX compiler identification is MSVC 19.34.31933.0
-- The C compiler identification is MSVC 19.34.31933.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.34.31933/bin/Hostx64/x64/cl.exe - skipped

[andreymerchenko]

thanks, @levlam! I'll check if MSVC can be downgraded or will try later (future) versions of MSVC to see if the issue is resolved there.

[levlam]

The https://developercommunity.visualstudio.com/t/Invalid-code-generation-in-release-1940/10678572 issue also mentions the possible cause of the crash now:

Programs that aren't following the documented restrictions on binary compatibility may encounter null dereferences in mutex machinery. You must follow this rule:
When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component.

Given that you have MSVC installed, it would be strange, if msvcp140.dll is from an old MSVC version, but this is listed as the only expected cause of the crash.

It also mentions a workaround. Namely, you can add the line
target_compile_definitions(tdutils PUBLIC _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR)
at

td/tdutils/CMakeLists.txt

Line 354 in b102c3a

.

If this helps, then the crash happens because of the ABI change in MSVC 19.40.33811.0.