Bug #2697
Execute several commands in a row using complex CQP queries leads to a JVM/cqpjni crash
Status: | Feedback | Start date: | 11/29/2019 | ||
---|---|---|---|---|---|
Priority: | Urgent | Due date: | |||
Assignee: | - | % Done: | 80% |
||
Category: | Development | Spent time: | - | ||
Target version: | TXM 0.8.1 |
Description
Execute several commands in a row using complex CQP queries leads to a JVM/cqpjni crash or a Visual C++ runtime crash (javaw.exe) (tested on Windows).
See some logs at the end of this issue.
Steps to reproduce¶
=> have a Partition based on a complex query, eg. ELTECFRAORIG_sp_n
=> launch TXM execute Index with "faire" query
=> execute another new Index and type another query (a second Index, not in the same Editor)
=> cqpjni crashes and the JVM too (with sometimes a Visual C++ runtime crash too)
cqpjni doesn't manage multi-thread access and concurrent queries. (Original CQP uses Sockets so the problem is not present since queries are linearly executed.)
Solutions to restrict and/or avoid this behavior¶
- define MemCqiClient methods as synchronized
=> will lead to errors but should stop crashes
Eclipse log:
Assertion failed! Program: C:\Tools\Coding\Java\jdks_txm\jdk1.8.0_202_win-x64\jre\bin\javaw.exe File: eval.c, Line 1037 Expression: rs && ls
Windows Events log:
Nom de l’application défaillante javaw.exe, version : 8.0.202.8, horodatage : 0x5c15d0df Nom du module défaillant : cqpjni.dll, version : 0.0.0.0, horodatage : 0x5ccbfcdd Code d’exception : 0x40000015 Décalage d’erreur : 0x0000000000044cf2 ID du processus défaillant : 0xe110 Heure de début de l’application défaillante : 0x01d5ac1544367a5b Chemin d’accès de l’application défaillante : C:\Tools\Coding\Java\jdks_txm\jdk1.8.0_202_win-x64\jre\bin\javaw.exe Chemin d’accès du module défaillant: C:\Tools\Coding\Java\workspace_txm2\org.txm.libs.cqp.win32\res\win64\cqpjni.dll ID de rapport : c238cdb5-1819-11ea-89af-005056c00008
Récipient d’erreurs , type 0 Nom d’événement : APPCRASH Réponse : Non disponible ID de CAB : 0 Signature du problème : P1 : javaw.exe P2 : 8.0.202.8 P3 : 5c15d0df P4 : cqpjni.dll P5 : 0.0.0.0 P6 : 5ccbfcdd P7 : 40000015 P8 : 0000000000044cf2 P9 : P10 : Fichiers joints : Ces fichiers sont peut-être disponibles ici : C:\Users\xxx\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_javaw.exe_fdfbe352e741d037c14b6ba92f3017caf2974ea9_c0202ac9 Symbole d’analyse : Nouvelle recherche de la solution : 0 ID de rapport : c238cdb5-1819-11ea-89af-005056c00008 Statut du rapport : 0
Other tests, executing several queries:
AFC de la partition ELTECFRAORIG_sp_n, propriété [word]... AFC de la partition ELTECFRAORIG_sp_n, propriété [word]... CQP Error: Illegal type (65535) of LHS argument in pattern. Warning: Evaluation interruted: results will be incomplete. # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000006dc426e0, pid=58868, tid=0x000000000000c4c8 # # JRE version: Java(TM) SE Runtime Environment (8.0_202-b08) (build 1.8.0_202-b08) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.202-b08 mixed mode windows-amd64 compressed oops) # Problematic frame: # C [cqpjni.dll+0x26e0] # # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # An error report file with more information is saved as: # C:\Tools\Coding\Java\eclipse-rcp-oxygen-3a-win32-x86_64\hs_err_pid58868.log # # If you would like to submit a bug report, please visit: # http://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. #
NOTE: I guess accessing a subcorpus not fully realized crashes cqpjni.dll.
Associated revisions
Defines all methods of MemCqiClient dealing with MemCqiServer as synchronized (refs #2697)
History
#1 Updated by Sebastien Jacquot over 3 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 80
New current state:
All methods of MemCqiClient dealing with MemCqiServer has been defined as synchronized.
=> it seems there are no crashes anymore
=> it can leads to some errors as "No such corpus", etc. when using multiple commands in a row
These errors must be managed by additional modifications, see: http://forge.cbp.ens-lyon.fr/redmine/issues/2682
Also need to carefully check that the synchronized blocks don't lead to deadlocks or other side effects.
#2 Updated by Sebastien Jacquot over 3 years ago
- Target version changed from TXM 0.8.2 to TXM 0.8.1