Библиотека SDL, которую я построил из исходных сбоев! - PullRequest
Новая
       11

Библиотека SDL, которую я построил из исходных сбоев!

1 голос
/ 16 августа 2010

Я успешно построил SDL из исходного кода, используя bcc 5.5.1, но любое тестовое приложение SDL, использующее его, сразу при запуске вылетает. Мне нужна помощь и / или руководство по решению этой проблемы.

Просто, чтобы заполнить некоторую информацию, использовался SDL-1.2.14. Проект скомпилирован как dll с поддержкой многопоточности и динамически связан с C-средой исполнения. Я также перестроил его с информацией отладки. Когда я прохожу с отладчиком до момента сбоя, кажется, он идет из redirect_stdout в sdlmain. Если я удаляю sdlmain.lib и использую исходный файл sdl_win32_main.c непосредственно в тестовом проекте SDL, то это больше не приводит к сбою. Вместо этого он просто вылетает позже в процедуре SDL_Init.

Я уже проверил используемые соглашения о вызовах, и все они, кажется, совпадают - все использует cdecl. Я также проверил и удостоверился, что скомпилированный sdl.dll и тестовое приложение использовали ту же самую динамическую среду выполнения c вместо статически связанной.

В вики SDL в разделе Borland упоминается использование -b, чтобы убедиться, что enum имеют тот же размер, что и int, но эта опция включена компилятором по умолчанию, если явно не отключена. Я перестроил SDL с этим переключателем компилятор / компоновщик, просто чтобы быть уверенным.

Когда происходит сбой, попытка записи по какому-либо адресу (c000005) всегда является нарушением прав доступа. Как, например, во время типичной попытки инициализации SDL, например: 

// initialize SDL video
if ( SDL_Init( SDL_INIT_VIDEO ) < 0 )
{
    printf( "Unable to init SDL: %s\n", SDL_GetError() );
    return 1;
}

После вызова SDL_Init () управление не возвращается обратно в тестовое приложение. Вместо этого он падает где-то странно, как где-то в ntdll.dll с чем-то, связанным с NTDLL.RtlEnterCriticalSection. Когда я проверяю трассировку стека в этой точке, я обычно получаю что-то вроде этого: 

:77982269
:0044A04C
:0043F02B
:0043F7C4
:0043EF25
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
SDL_CreateMutex()
SDL_CreateSemaphore(1)
//and it keeps recursing... looks like a stackover? :P

Я не уверен, что попробовать в этой точке, потому что я довольно тупой. Если у кого-то есть какие-либо предложения или мне нужна дополнительная информация, пожалуйста, не стесняйтесь добавлять ее в комментарии.

Спасибо

1 Ответ

3 голосов
/ 20 августа 2010

Хорошо, я наконец выяснил, в чем проблема пару дней назад.Причиной сбоя было то, что для данной платформы был скомпилирован неверный исходный файл.

Файл проекта, который я использовал, продолжал компилировать SDL_sysmutex.c из threads \ generic.Правильный файл SDL_sysmutex.c для использования под win32 должен был быть из потоков \ win32.Я узнал об этом, когда шел рядом с тестовыми программами, и у потоковых модулей были разные строки кода!

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

...