Помогите новичку
-
Как отладчик не ловит ? Он все исключения перехватывает, даже в ядре.
Пишет, что, мол, exception 0E. В поле дизассемблированного кода пусто. В регистрах какие-то значения.
Очень даже ловит.
Посмотри значение eip. Вышел за границу памяти приложения. Отсюда страничное нарушение.
Или исключение было в ядре.
Посмотри значение eip. Вышел за границу памяти приложения. Отсюда страничное нарушение.
Или исключение было в ядре.
Управление программой улетает на область памяти, и комп выполняет mov eax, al (00h 00h) пока память не кончится.
Я догадываюсь, чем такое поведение может быть вызвано в теории, но не догадываюсь, почему не происходит переход на Screen_Init.
Я догадываюсь, чем такое поведение может быть вызвано в теории, но не догадываюсь, почему не происходит переход на Screen_Init.
Здесь только трассировка поможет. Ставишь в коде перед нужными функциями
asm volatile("int3");
и запускаешь в отладчике. Внимательно смотришь стек перед входом в функцию и после. Если после возврата из функции поменялось значение esp значит произошла путаница с cdecl и stdcall
объявлениями, надо проверять заголовочные файлы. Это одна из возможных причин.
asm volatile("int3");
и запускаешь в отладчике. Внимательно смотришь стек перед входом в функцию и после. Если после возврата из функции поменялось значение esp значит произошла путаница с cdecl и stdcall
объявлениями, надо проверять заголовочные файлы. Это одна из возможных причин.
Сурово, блин. Спасибо за помощь!
Долгая, нудная, неблагодарная работа.
Вот потому я и предлагал почесаться.
Mario
Твоё предложение мало поможет. А вот отладчик в исходных кодах для отладки программ на яву очень даже пригодился бы.
Твоё предложение мало поможет. А вот отладчик в исходных кодах для отладки программ на яву очень даже пригодился бы.
Что-то вроде GDB?
Только GUI. Без нескольких окон в отладчике делать нечего.
Ха, Serge, спасибо! Я разобрался получше с отладчиком, и выяснил, что мой компилятор "немного оптимизировал" код, в результате в лог выводилась информация уже после крэша. А крэш происходит в процедуре memset (что странно, раньше не происходил)
И опять тупняк.
screen.c
screen.h
Похоже, эта команда забивает всё-всё нулями.
Нужно убедиться, что зависает точно на ней/строго после неё, затем посмотреть на sizeof(FRAMEBUFFER) и если всё похоже на правду, то ковырять memset, правильно?
screen.c
Code: Select all
/* extern for video.c */
FRAMEBUFFER *pFrameBuffer; /* Pointer into current 'FrameBuffer' */
static FRAMEBUFFER FrameBuffers[NUM_FRAMEBUFFERS]; /* Store frame buffer details to tell how to update */
memset(FrameBuffers, 0, NUM_FRAMEBUFFERS * sizeof(FRAMEBUFFER));
Code: Select all
#define HBL_PALETTE_LINES ((NUM_VISIBLE_LINES+1)*16)
/* Bit mask of palette colours changes, top bit set is resolution change */
#define HBL_PALETTE_MASKS (NUM_VISIBLE_LINES+1)
/* Frame buffer, used to store details in screen conversion */
typedef struct
{
Uint16 HBLPalettes[HBL_PALETTE_LINES];
Uint32 HBLPaletteMasks[HBL_PALETTE_MASKS];
Uint8 *pSTScreen; /* Copy of screen built up during frame (copy each line on HBL to simulate monitor raster) */
Uint8 *pSTScreenCopy; /* Previous frames copy of above */
int OverscanModeCopy; /* Previous screen overscan mode */
bool bFullUpdate; /* Set TRUE to cause full update on next draw */
} FRAMEBUFFER;
/* Number of frame buffers (1 or 2) - should be 2 for supporting screen flipping */
#define NUM_FRAMEBUFFERS 2
Нужно убедиться, что зависает точно на ней/строго после неё, затем посмотреть на sizeof(FRAMEBUFFER) и если всё похоже на правду, то ковырять memset, правильно?
Возможно, но буфер статический, все размеры и адреса определяются ещё на этапе компиляции. memset скорее всего без ошибок. Надо смотреть map файл, где именно этот буфер, какой у него размер и что там может потереться.
В map-файле нет FrameBuffers. Это нормально?
Who is online
Users browsing this forum: No registered users and 2 guests