Проблема в B-дереве (не B+/B*), реализованная с файлами на C

Код немного сложно читать, но вот что я вижу:

R = (Nod*)realloc(R,sizeof(Nod));
R = raiz;

Вы делаете выделение памяти и сразу выбрасываете результат. Результат realloc может отличаться от исходного указателя.

Вы, вероятно, хотите, чтобы функция инициализировала узлы вашего дерева, чтобы сделать это более понятным - мне трудно следовать коду.

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

РЕДАКТИРОВАТЬ: Если все дерево построено в файле (что, по-видимому, является намерением, глядя на это немного больше), вам, вероятно, вообще не нужно выполнять какое-либо динамическое выделение памяти.

В общем случае вы хотите:

• Следите за переполнением, например. вы пишете в ячейку памяти за пределами того, что доступно/было выделено, строковые функции восприимчивы к ним, убедитесь, что у вас всегда есть допустимая строка с нулевым завершением, где это требуется, и у вас всегда есть достаточно места для вашей строки (то есть это не дольше, чем вы можете держать).
• Проверьте возвращаемые значения NULL из функций выделения памяти.
• Убедитесь, что вы не пропускаете память, т.е. выделяете и выбрасываете указатель, никогда не вызывая free().
• Убедитесь, что вы всегда вызываете free с ранее выделенным указателем и не используете этот указатель в какой-либо более поздней точке.
• Кажется, есть много мест, где вы делаете realloc(), но действительно хотите использовать malloc().

Некоторые компиляторы C/C++ могут выполнять дополнительные проверки во время выполнения (например, Visual Studio), которые могут быть полезны для выявления проблемы.

Также обратите внимание на хорошие комментарии Джонатана относительно условностей и стиля.

Файлы заголовков должны содержать только объявления структур, определения типов, перечисления, определения и объявления функций. Возможно, у вас есть встроенные определения функций, но, вероятно, нет.

В вашем заголовочном файле есть полные функции - те, которые вряд ли будут встроены и не объявлены встроенными. Это означает, что он непригоден для использования по прямому назначению — для предоставления объявлений файлам с использованием кода, определенного в соответствующем файле C.

Код нелегко читать, и проблема не в языке. Такие конструкции, как:

while ( (i >= 1) && (strcmp(val,x->chave[i]) < 0) ) {i--;}

не являются идиоматическими C. Обычный способ написания:

while (i >= 1 && strcmp(val, x->chave[i]) < 0)
    i--;

Существуют рекомендации по кодированию, которые требуют фигурных скобок вокруг всех тел циклов и условных выражений; если вы страдаете от одного из них, то вы используете одно из нескольких соглашений о кодировании:

while (i >= 1 && strcmp(val, x->chave[i]) < 0)
{
    i--;
}

while (i >= 1 && strcmp(val, x->chave[i]) < 0) {
    i--;
}

Я решительно предпочитаю первое; есть много людей, которые предпочитают последнее.

В этом мире есть системы, отличные от Windows и Linux.

//defs of pre-compiler
#ifdef __linux
    #define PAUSA "read p"
    #define CLRSCR "clear"
#else
    #define PAUSA "Pause"
    #define CLRSCR "cls"
#endif

Это не совсем разумно работает для моей среды — MacOS X. Я не особо увлекаюсь программами, использующими системные операторы, но я думаю, что проблема в том, что я старый дурак, который не использует и IDE (хотя один одна из причин, по которой я не использую IDE, заключается в том, что программы командной строки не работают в них нормально, а я в основном пишу программы командной строки, поэтому они враждебны моему обычному режиму работы).

Одна из основных ошибок производительности:

for (i = 0; i < fSize(arqt); i++)

Это вызывает функцию fSize() на каждой итерации, и функция проходит по всему файлу, определяя, сколько строк в файле, восстанавливая позицию чтения перед возвратом. Неясно, действительно ли вам нужно считать количество строк — вы, вероятно, можете просто читать строки по ходу дела. Однако, если вам нужно посчитать строки, сделайте это только один раз.

int lines = fSize(arqt);
for (i = 0; i < lines; i++)

Есть ряд мест, где у вас есть циклы, использующие:

for (x = 1; x <= MAX; x++)

Обычно это неверно в C; индексы массива начинаются с нуля, а каноническая форма цикла такова:

for (x = 0; x < MAX; x++)

Стилистически вы обычно резервируете все имена в верхнем регистре для значений #define или enum, а не для обычных переменных.

В функции insere_b() у вас есть:

//B-TREE-INSERT //i believe the problem is here!
void insere_b(char *val)
{
    Nod *S = NULL, *R = NULL;

    R = (Nod*)realloc(R, sizeof(Nod));
    //R = raiz;

    if (R->num == Max)
    {
        S = (Nod*)realloc(S, sizeof(Nod));

Кто-то еще указал, что строка R = raiz; сомнительна. Вы присваиваете null R; то вы realloc() его. Это всегда эквивалентно malloc(). Кроме того, выделенная память не инициализируется, поэтому вы получаете случайные значения для игры. Это приводит к проблемам.

Затем вы выполняете аналогичную последовательность с S (выделение памяти через realloc()), хотя на этот раз вы последовательно инициализируете части (возможно, все) выделенной структуры.

Этого достаточно, чтобы вызвать проблемы.

Когда код входит в b_split() в первый раз, вы сталкиваетесь с проблемой со значениями позиции. В частности, y->pos равно нулю, но x->pos тоже, поэтому программа сохраняет (записывает) данные на два узла с одинаковым смещением, что редко является рецептом счастья. Так как x является корневым узлом (по крайней мере, в этом контексте - первое разделение), он должен быть в позиции 0; оба y и z должны быть в разных позициях. Узел y также содержит ненулевые ключи, хотя это не имеет большого значения (за исключением целей аккуратности), поскольку значение y->num указывает, что они не используются.

Вы также никогда не используете значение ключа chave[0], AFAICT. Это немного расточительно.