Тот же код не будет работать (вроде) в общей библиотеке, но работает при использовании непосредственно в программе

Question

Я создал язык сценариев, когда он работал отлично, я поместил весь код в общую библиотеку и сделал для него, но тот же код не будет работать в общей библиотеке. Я заметил, что код работает быстрее в общей библиотеке, но он всегда сбой из-за проблем с памятью, говоря, что индекс не имеет длины массива, но тот же код отлично работает за пределами библиотеки.
Я также заметил, что если я уменьшу объем работы, которую он должен выполнить, он длится немного дольше, чем рухнет.

Мой вопрос здесь в том, что вызывает этот крах, и как я могу остановить его?

PS: Я не включил весь код, потому что весь код имеет 1039 строк (но если вам нужен код для решения проблемы, то я мог бы ссылаться на него), но я отслеживал сбой на функция. И запутанным является то, что функция всегда вылетает в 821-й раз, когда она вызывается, никогда раньше, это для более оптимизированного кода, когда код не был оптимизирован и использовался больше CPU, он сработал бы при 702.

Plus : Я использую DMD2, и функции экспортируются с помощью extern (C), и я тестирую все это в системе Linux, Ubuntu 14.04. И вот как я скомпилирую библиотеку:

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 

И загружается с использованием функции dlopen.

Опять же, если вы пропустили мой вопрос: что вызывает этот крах, и как я могу остановить его? EDIT: и как я могу отключить сборщик мусора, gc.disable не работает, gc не определен.

EDIT: Я отслеживал «почему» произошел сбой, я установил код отладки по всем файлам, чтобы узнать, что сборщик мусора возился с файлом сценария, который был загружен в память. Я «исправил» проблему, а не на самом деле, добавив чек. Он проверяет, не является ли скрипт «хорошо», он перезагружает его в память. Это предотвращает крах, но проблема все еще существует. Это меняет вопрос на:
Как отключить сборщик мусора> BTW, я пробовал gc.disable, но DMD говорит, что gc не определен.

Answer 1

Вы должны инициализировать среду выполнения, когда вы загружаете свою общую библиотеку в первый раз. Для этого вам нужно добавить что-то подобное в вашей библиотеке:

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; 
} 

я действительно имею в виду как этот и не точно, что. Так как мы не знаем, как используется ваш скриптовый движок инициализации счетчика может также быть действительным:

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; 
} 

В любом случае вы должны получить идею. GC не был определен, потому что вы не инициализируете время выполнения D низкого уровня.

Answer 2

Решил проблему самостоятельно. Как я сказал в Редактировании Вопроса: я отследил проблему с сборщиком мусора, сборщик мусора возился с файлом сценария, который был загружен в память, что вызвало сбой библиотеки, потому что сборщик мусора удалил содержимое скрипта из память. Чтобы решить эту проблему, я добавил:

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

Это решило всю проблему.