Bug #2181

RCP: 0.7.8 Linux, direct crash on various CQP access

Added by Serge Heiden over 2 years ago. Updated 9 months ago.

Status:New Start date:05/04/2017
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:Setup Spent time: -
Target version:TXM 0.8.1

Description

For various commands using CQP access like Index, Back to text from Concordance, etc. TXM can crash at any moment.

Hypothesis

A suggestion from AL is that some JVM low memory configurations could provoke such a behavior. So some new "-Xms -Xmx" JVM launching parameters could help.

If we look at how TXM is launched on Linux:
  • inside /usr/share/applications/TXM.desktop
  • we find the /usr/bin/TXM call
  • which needs to access $HOME/TXM/.txm that doesn't exist
    • no ".txm" file means no default values for JVM launch so no tuning of type "-Xms512m -Xmx1024m" available to get a bigger memory model.

Solution

There should be a ticket about changing the '.txm' file directory in TXM directories architecture for Windows, and probably Linux (?), that may be related to this problem but I can't find any.

Annex (JVM crash backtrace)

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f8c9e22ccc0, pid=32428, tid=140241937426176
#
# JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 1.7.0_75-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libc.so.6+0x4ecc0]  _IO_vfprintf+0x1b50
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

...

Stack: [0x00007f8c9ecce000,0x00007f8c9edcf000],  sp=0x00007f8c9edc9320,  free space=1004k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc.so.6+0x4ecc0]  _IO_vfprintf+0x1b50
C  [libc.so.6+0x4fef1]  _IO_vfprintf+0x2d81

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.txm.searchengine.cqp.MemCqiServer.cqpQuery(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/Boolean;+0
j  org.txm.searchengine.cqp.MemCqiClient.cqpQuery(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)V+7
j  org.txm.searchengine.cqp.corpus.MainCorpus.getStartLimits(Ljava/lang/String;)[I+35
j  org.txm.functions.concordances.Concordance.getLines(II)Ljava/util/List;+164
j  org.txm.rcpapplication.editors.concordances.ConcordancesEditor.fillDisplayArea(II)V+46
j  org.txm.rcpapplication.editors.concordances.ConcordancesEditor.compute(IIZ)V+348
j  org.txm.rcpapplication.editors.concordances.ConcordancesEditor.compute(Z)V+9
j  org.txm.rcpapplication.editors.concordances.ConcordancesEditor.compute()V+2
j  org.txm.rcpapplication.commands.link.IndexToConcordance.link(Lorg/txm/rcpapplication/editors/index/IndexEditor;Lorg/eclipse/jface/viewers/IStructuredSelection;)Ljava/lang/Object;+96
j  org.txm.rcpapplication.editors.index.IndexEditor$11.mouseDoubleClick(Lorg/eclipse/swt/events/MouseEvent;)V+64

Diagnostic

CQP crashes and so is TXM because they share the same memory (JNI).

The SIGSEV error is raised when vfprintf is called within CQP.

In CQP code, vfprintf is called at 2 different moments :
  • in regex2dfa.c in the "REGEX2DFA_ERROR" static procedure:
          fprintf(stderr, "%s:\n\t", msg);
          vfprintf(stderr, format, ap);
          fprintf(stderr, "\n");
  • in output.c in the "cqpmessage" procedure:
      fprintf(stderr, "[%d] ", LINE);
      va_start(AP, Format); vfprintf(stderr, Format, AP); va_end(AP);
      fputc('\n', stderr);

History

#1 Updated by Serge Heiden over 2 years ago

  • Description updated (diff)
  • Category set to Setup
  • Target version set to TXM 0.7.8

#2 Updated by Matthieu Decorde over 2 years ago

  • Description updated (diff)

#3 Updated by Matthieu Decorde about 2 years ago

  • Target version changed from TXM 0.7.8 to TXM 0.8.0a (split/restructuration)

not reproduced since report

#4 Updated by Matthieu Decorde 9 months ago

  • Target version changed from TXM 0.8.0a (split/restructuration) to TXM 0.8.1

Also available in: Atom PDF