2016-05-02 5 views
2

J'ai créé un langage de script, quand cela a fonctionné parfaitement, j'ai mis tout le code dans une bibliothèque partagée, et fait un wrapper pour cela, mais le même code ne fonctionnera pas dans la bibliothèque partagée. J'ai remarqué que le code s'exécute plus rapidement dans la bibliothèque partagée, mais il se bloque toujours, en raison de problèmes de mémoire, en disant que l'index est hors de la longueur du tableau, mais le même code s'exécute parfaitement.
J'ai également remarqué que si je réduis la quantité de travail à faire, cela dure un peu plus longtemps avant de tomber en panne.Même code ne fonctionnera pas (sorte de) dans une bibliothèque partagée, mais fonctionne lorsqu'il est utilisé directement dans le programme

Ma question ici est que ce qui cause ce crash, et comment puis-je l'empêcher de se produire? PS: Je n'ai pas inclus tout le code, parce que le code entier est de 1039 lignes (mais si vous avez besoin du code pour résoudre le problème, alors je pourrais le lier), mais j'ai suivi le crash à un fonction. Et la confusion est que cette fonction se bloque toujours à la 821ème fois qu'elle s'appelle, jamais avant, c'est pour un code plus optimisé, quand le code n'était pas optimisé, et utilisait plus de CPU, il planterait à 702.

Plus : J'utilise DMD2, et les fonctions sont exportées en utilisant extern (C), et je suis en train de tester tout cela sur un système Linux, Ubuntu 14.04. Et voici comment je compile la bibliothèque:

dmd -debug -gc "qscript.d" "qcompiler.d" "lists.d" "dllmain.d" "-shared" "-odobj/Debug" "-of/home/nafees/Desktop/Projects/QScr/QScr/bin/Debug/libQScr.so" -w -vcolumns 

Et est chargé en utilisant la fonction dlopen.

Encore une fois si vous avez manqué ma question: qu'est-ce qui cause cet accident, et comment puis-je l'empêcher de se produire? EDIT: et comment puis-je désactiver le garbage collector, gc.disable ne fonctionne pas, gc est indéfini.

EDIT: J'ai suivi «pourquoi» le crash se produit, j'ai mis en place du code de débogage sur tous les fichiers, juste pour découvrir que le garbage collector joue avec le fichier script qui a été chargé dans la mémoire. J'ai 'résolu' le problème, pas réellement, en ajoutant un contrôle. Il vérifie si le script n'est pas 'correct', il le recharge dans la mémoire. Cela évite le crash, mais le problème existe toujours. Cela change la question à:
Comment puis-je désactiver le garbage collector> BTW, j'ai essayé gc.disable, mais le DMD dit que gc est indéfini.

+0

[MVCE] (http://stackoverflow.com/help/mcve) requis. –

+0

J'ai mis à jour la question, maintenant je dois désactiver le garbage collector. – Nafees

Répondre

2

Vous devez initialiser le moteur d'exécution lorsque vous chargez votre bibliothèque partagée pour la première fois. Pour ce faire, vous devez ajouter quelque chose comme ça à votre bibliothèque:

private __gshared bool _init = false; 
import core.runtime: rt_init, rt_term; 

export extern(C) void init() 
{ 
    if (!_init) rt_init; 
} 

export extern(C) void terminate() 
{ 
    if (_init) rt_term; 
    _init = false; 
} 

Je veux dire vraiment comme ça et non exactement que. Comme nous ne savons pas comment votre moteur de script est utilisé, un compteur init peut également être valide:

private __gshared uint _init; 
import core.runtime: rt_init, rt_term; 

export extern(C) void init() 
{ 
    if (!_init) rt_init; 
    ++init; 
} 

export extern(C) void terminate() 
{ 
    --init; 
    if (!_init) rt_term; 
} 

De toute façon vous devriez avoir l'idée. Le GC était indéfini car vous n'initialisiez pas le runtime D de bas niveau.

0

J'ai résolu le problème moi-même. Comme je l'ai dit dans l'édition de la Question: J'ai dépisté le problème au garbage collector, le ramasse-miettes était en train de jouer avec le fichier script qui a été chargé dans la mémoire, car le garbage collector avait enlevé le contenu du script. la mémoire. Pour résoudre ce problème, j'ai ajouté:

import core.memory; 
... 
GC.disable(); 

Cela a résolu tout le problème.

+0

La désactivation du CPG couvre juste le problème. Comme Mike l'a demandé, postez un MCVE afin que nous puissions trouver le vrai problème. Je suppose que vous passez la mémoire allouée par le GC à une bibliothèque C, où D ne la recherche pas. –

+0

Je posterai le MVCE demain, il ne me reste plus beaucoup de temps. Et le crash était dans la bibliothèque, et l'hôte n'était en aucun cas lié au crash, l'hôte n'appelait qu'une fonction (de la lib), lui passant le chemin du script. – Nafees

+0

La bibliothèque conserve-t-elle une référence à cette chaîne de chemin? Si c'est le cas, alors il peut être recueilli; le D GC ne connaît pas la référence que les bibliothèques C contiennent. –