Bug #2697

Execute several commands in a row using complex CQP queries leads to a JVM/cqpjni crash

Added by Sebastien Jacquot over 3 years ago. Updated over 3 years ago.

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

  1. 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

Revision 2447
Added by Sebastien Jacquot over 3 years ago

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

Also available in: Atom PDF