Laboratoire ICAR » Plateforme TXM

BP

         il arrive que le calcul échoue ; c'est difficile à reproduire et cela n'échoue pas non plus toujours de la même façon (stacktrace ou non, TXM grisé ou non), sinon que dans tous ces cas le calcul n'aboutit pas. Ce n'est pas marginal, dans le contexte dans lequel je travaillais et en essayant de reproduire le bug j'ai dû réussir à planter TXM entre 5 et 10 fois en 30 mn. Il semble que ce soit lié au fait de demander un calcul de spécificités sur sous-corpus alors qu'un précédent traitement (par exemple un export un peu gros) n'est pas encore achevé : comme si le calcul se lance sans vérifier que tout le reste est fini. Voici un cas où on peut arriver à produire le bug :
            sur le corpus AFVOIXOFFV02, calculer le sous-corpus avancé commemoration52sujets avec la requête :

<div>[_.div_identifiant-de-la-notice="AFE86003334|AFE85001757|AFE85001758|AFE85002810|AFE85002811|AFE85002812|AFE85002208|AFE85002209|AFE85002210|AFE85003294|AFE85003810|AFE85004314|AFE85004816|AFE85005345|AFE85005346|AFE85007136|AFE85006464|AFE85007039|AFE85007637|AFE85008889|AFE85008890|AFE85009295|AFE85009716|AFE86000450|AFE86001304|AFE86003099|AFE85001424|AFE85002498|AFE85002499|AFE85002501|AFE85002502|AFE85001996|AFE85003069|AFE85003532|AFE85004556|AFE85004557|AFE85005074|AFE85005607|AFE85005608|AFE85005609|AFE85006145|AFE85007392|AFE85008288|AFE85008287|AFE85008675|AFE85009076|AFE85009513|AFE85009923|AFE85010276|AFE86000272|AFE86000593|AFE86000912" | _.div_identifiant-de-la-notice="AFE85001995" | (_.text_date-de-diffusion="15/11/1951|13/05/1954" & _.div_id="1") ] expand to div

    calculer spécificités sur word
    exporter
    puis aussitôt calculer spécificités sur frlemma, j'ai dans ce cas obtenu la stacktrace :

org.rosuda.REngine.Rserve.RserveException: Error while processing eval output: SEXP (type 10) expected but found result type 44.
    at org.rosuda.REngine.Rserve.RConnection.parseEvalResponse(RConnection.java:207)
    at org.rosuda.REngine.Rserve.RConnection.eval(RConnection.java:233)
    at org.txm.statsengine.r.core.RWorkspace.safeEval(RWorkspace.java:1548)
    at org.txm.statsengine.r.core.RWorkspace.eval(RWorkspace.java:1141)
    at org.txm.statsengine.r.core.data.VectorImpl.asStringsArray(VectorImpl.java:240)
    at org.txm.specificities.core.functions.Specificities.getTypeNames(Specificities.java:451)
    at org.txm.specificities.core.functions.Specificities.toTxt(Specificities.java:564)
    at org.txm.rcp.handlers.export.ExportResult$1.run(ExportResult.java:147)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
** Échec de l'exportation du résultat @frlemma : java.lang.NullPointerException
java.lang.NullPointerException
    at org.txm.statsengine.r.core.data.VectorImpl.asStringsArray(VectorImpl.java:241)
    at org.txm.specificities.core.functions.Specificities.getTypeNames(Specificities.java:451)
    at org.txm.specificities.core.functions.Specificities.toTxt(Specificities.java:564)
    at org.txm.rcp.handlers.export.ExportResult$1.run(ExportResult.java:147)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)

Hypothesis¶

Deadlock produced when the export is not done and a new command is called ?
The result is not ready or is being computed ?

Solution¶

- if aborted the specificities result must release its R semaphore
- export is making to much R acess data command
- don't re-compute a result before exporting if not dirty
- a TXMResult must not be exported if it is currently in computing state