Closed andreymerchenko closed 4 months ago
levlam
commented
5 months ago 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
commented
5 months ago 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
commented
5 months ago 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
commented
5 months ago 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
commented
4 months ago Could you try with have just pushed commit?
andreymerchenko
commented
4 months ago 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
commented
4 months ago 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
commented
4 months ago 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
commented
4 months ago 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
commented
4 months ago 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
commented
4 months ago 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
commented
4 months ago What's your MSVC version and your colleague's MSVC version?
andreymerchenko
commented
4 months ago 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
levlam
commented
4 months ago 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.
andreymerchenko
commented
4 months ago 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
commented
4 months ago 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 https://github.com/tdlib/td/blob/b102c3adef5428142671b51d1989ce00ce7a4525/tdutils/CMakeLists.txt#L354.
If this helps, then the crash happens because of the ABI change in MSVC 19.40.33811.0.
nguyenkatd
commented
2 months ago hello sir @levlam , im facing the same issue, how to fix it:
#
#
#
#
#
#
levlam
commented
2 months ago @nguyenkatd
Did you try to build TDLib with _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR as specified in https://github.com/tdlib/td/issues/2912#issuecomment-2156135946?
nguyenkatd
commented
2 months ago Thanks much, already resolved it @levlam , now im trying to find some ways to import the lib to my spring boot project. Do you have some tutorials about it ?
levlam
commented
2 months ago @nguyenkatd No, but this isn't different from any other shared library with JNI interface.
avielt10
commented
2 months ago It also mentions a workaround. Namely, you can add the line
target_compile_definitions(tdutils PUBLIC _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR)at
Worked for me. thanks.
MrKangZuBin
commented
2 months ago 未遵循已记录的二进制兼容性限制的程序可能会在互斥机制中遇到空引用取消引用。您必须遵循以下规则： 当您混合使用不同受支持版本的工具集构建的二进制文件时，可再发行版本必须至少与任何应用组件使用的最新工具集一样新。
假设您已经安装了 MSVC，如果 msvcp140.dll 来自旧的 MSVC 版本，那将会很奇怪，但这被列为崩溃的唯一预期原因。
它还提到了一种解决方法。也就是说，你可以
target_compile_definitions(tdutils PUBLIC _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR)在。 如果这有帮助，那么崩溃就是因为 MSVC 19.40.33811.0 中的 ABI 变化而发生的。
添加了还是错误
Hi tdlib community,
I am currently experiencing issues in running Example on the latest tdlib build.
The build was performed from the following git commit: Add separate tl_generate_mtproto target..
Error:
# A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff833ae32a8, pid=5372, tid=33568 # # 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:
--------------- S U M M A R Y ------------
Command Line: -javaagent:C:\app\Idea\lib\idea_rt.jar=60062:C:\app\Idea\bin -Dfile.encoding=UTF-8 org.drinkless.tdlib.example.Example
Windows 11 , 64 bit Build 22621 (10.0.22621.3672) Time: Mon Jun 3 22:23:01 2024 Belarus Standard Time elapsed time: 0.236629 seconds (0d 0h 0m 0s)
--------------- T H R E A D ---------------
Current thread (0x0000025a6e603320): JavaThread "main" [_thread_in_native, id=32872, stack(0x000000ae15a00000,0x000000ae15b00000)]
Stack: [0x000000ae15a00000,0x000000ae15b00000], sp=0x000000ae15afea60, free space=1018k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [msvcp140.dll+0x12c10] C [tdjni.dll+0x6df168]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.drinkless.tdlib.Client.nativeClientExecute(Lorg/drinkless/tdlib/TdApi$Function;)Lorg/drinkless/tdlib/TdApi$Object;+0 j org.drinkless.tdlib.Client.execute(Lorg/drinkless/tdlib/TdApi$Function;)Lorg/drinkless/tdlib/TdApi$Object;+1 j org.drinkless.tdlib.example.Example.main([Ljava/lang/String;)V+19 v ~StubRoutines::call_stub
siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000000000000
Could you, please, check this issue?
Thank you.