Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > C/C++: Системное программирование и WinAPI > Зависание винды при установки брейкпоинта


Автор: neosapient 21.4.2007, 21:34
Доброе время суток, Всем.

В общем жалавался я уже на свою проблему, но похоже виновником ошибся, а проблема осталась.

Пользуюсь VC7 (и на VC6 проверял - теже тормаза)
Есть главный поток, отвечающий за GUI. Он запускает дочерний поток, который делает расчеты.
Так вот, я хочу проверить правильность работы алгоритма и я ставлю брейкпоинт в начале алгоритма, вставленого в дочерний поток. 

И тут ... всё начинает по сумашедшиму тормазить  smile. Запускаю диспетчер задач и вижу, что процессор не загружен, что никто файлом подкачки активно не пользуется. А между тем контролы различных приложений, резко тормазят в реакциях на события.

Так было и пол года назад, я думал, что проблемы вызывает антивирус, но...
Получив новое задание (в котором без отладки кода в дочернем потоке не обойтись) и помня о замарочках, я поставил голую винду и на неё VC6, а тормаза остались.
Вывод: тормаза возникают из-за внутренних конфликтов с правами доступа для трассировки дочернего(их) потока(ов)

КАК УБРАТЬ ТОРМАЗА???
 smile 

Автор: W4FhLF 22.4.2007, 07:46
Пользуйся нормальными отладчиками, вроде тех, что в IDA или OllyDBG. 

И определись что тебе всё-таки надо:

Цитата(neosapient @  21.4.2007,  21:34 Найти цитируемый пост)
 вставленого в дочерний поток. 


или

Цитата(neosapient @  21.4.2007,  21:34 Найти цитируемый пост)
в котором без отладки кода в дочернем процессе не обойтись


Процесс или поток? 

+ приоритеты процессов посмотри, одинаковые?

Автор: neosapient 22.4.2007, 11:17
Цитата

Процесс или поток? 


Потоки (а там опечатка, я её исправил)

Цитата

приоритеты процессов посмотри, одинаковые?

Я приоритеты не меняю, так что по умолчанию

Автор: korbian 23.4.2007, 09:52
 smile 
Давай исходник дочернего потока.
Была схожая проблема, loop-ился в главной фнукции до ожидания заполнения структуры данных(постоянно!!!), исправил синхронизацией, с использованием мьютекса или евента.

Автор: Earnest 23.4.2007, 10:55
neosapient, вывод однозначный: что-то не так с твоими потоками. Потому что правильные потоки отлаживаются в VC 6 совершенно нормально. Нужен не только исходник потоковой функции, но и код запуска.
А может ты условную точку прерывания ставишь? Тогда не только интерфейс - все тормозит по страшному...  

Автор: korbian 23.4.2007, 12:05
Цитата(Earnest @  23.4.2007,  11:55 Найти цитируемый пост)
А может ты условную точку прерывания ставишь?

Это как, поясни, пожалуйста?

Автор: Earnest 23.4.2007, 19:12
Как-как... точка прерывания, которая срабатывает не при любом прохождении потока управления через нее, а при выполнении заданного условия. Ну скажем, тебе надо в цикле из 1000 итераций отладить 654-ю. Не будешь же ты 653 раза на Run жать... "Обычные" точки прерывания реализуются подменой команды в коде, а условные - это, надо полагать, уже накрутка в среде, вот и тормозят не по-детски...

Автор: neosapient 23.4.2007, 19:27
Цитата(korbian @  23.4.2007,  09:52 Найти цитируемый пост)
Давай исходник дочернего потока.


Прикрепил в приложении

А брейк поинт ставлю в функции GenerateSymbol()Save2DMassive(...)Load2DMassive(...)
Которые вызываются из потока ThreadFunc(...)

Код

// подключаем стандартные контролы
#include <windows.h>
#include <mmsystem.h>        // Подключаем системную библеотеку 
#pragma comment (lib,"Winmm.lib")
//#include <stdlib.h>
//#include <stdio.h>
#include <time.h>
#include <math.h>

#include "resource.h"

HINSTANCE hInst;
HWND hMainDlg;
HANDLE hThread;

#define NUM_SYMB 3

#define START_SYMBOL 'a'
#define FILE_NAME_Symbol "_Symbol.txt"
unsigned char Symbol[NUM_SYMB];

#define ASC(a) a<0?-a:a
void GenerateSymbol(void)
{
    int i;
    for(i=0;i<NUM_SYMB;i++){
        Symbol[i]=START_SYMBOL+i;
    }
}

void Save2DMassive(char* pzFileName, unsigned char * pMas, int y, int x, int SizeOf)
{
    int i,j,k;
    DWORD retFile;
    if(pzFileName!=NULL&&pMas!=NULL){
        //FILE* file;
        //file = fopen(pzFileName,"w");
        HANDLE m_file=CreateFile(pzFileName,GENERIC_WRITE,FILE_SHARE_READ | FILE_SHARE_WRITE,
                        NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL);
        for(j=0;j<y;j++){
            for(i=0;i<x;i++){
                //for(k=0;k<SizeOf;k++){
                    //putc(*(pMas+(j*x+i)*SizeOf+k),file);
                //}
                WriteFile(m_file,(pMas+(j*x+i)*SizeOf),SizeOf,&retFile,NULL);
            }
            //putc('\n',file);
            WriteFile(m_file,"\r\n",2,&retFile,NULL);
        }
        //fclose(file);
        CloseHandle(m_file);
    }
}

void Load2DMassive(char* pzFileName, unsigned char * pMas, const int y, const int x, int SizeOf)
{
    int i,j,k;
    char buf[2];
    DWORD retFile;
    if(pzFileName!=NULL&&pMas!=NULL){
        //FILE* pFile;
        //pFile = fopen(pzFileName,"r");
        HANDLE m_file=CreateFile(pzFileName,GENERIC_READ,FILE_SHARE_READ | FILE_SHARE_WRITE,
                        NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
        for(j=0;j<y;j++){
            for(i=0;i<x;i++){
                //for(k=0;k<SizeOf;k++){
                    //*(pMas+(j*x+i)*SizeOf+k) = getc(pFile);
                //}
                ReadFile(m_file,(pMas+(j*x+i)*SizeOf),SizeOf,&retFile,NULL);
            }
            ReadFile(m_file,buf,2,&retFile,NULL);
        }
        //fclose(pFile);
        CloseHandle(m_file);
    }
}

DWORD WINAPI ThreadFunc( LPVOID lpParam ) 
{
    GenerateSymbol();
    Save2DMassive(FILE_NAME_Symbol,(unsigned char *)Symbol,1,NUM_SYMB,sizeof(unsigned char));
    Load2DMassive(FILE_NAME_Symbol,(unsigned char *)Symbol,1,NUM_SYMB,sizeof(unsigned char));

    return 0;



BOOL  CALLBACK DlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
    int wmId, wmEvent;
    switch (message) 
    {
    case WM_INITDIALOG:
        hMainDlg  = hDlg;
        hThread = CreateThread(NULL, 0, ThreadFunc, 0, 0, 0);
        break;
    case WM_COMMAND:
        wmId    = LOWORD(wParam); 
        wmEvent = HIWORD(wParam); 
        // Parse the menu selections:
        switch (wmId)
        {
        case IDOK:
            break;
        case IDCANCEL:
            DestroyWindow(hDlg);
            break;
        }
        break;
    case WM_DESTROY:
        PostQuitMessage(0);
        break;
    default: 
        return FALSE; 
    }
return TRUE;
}

int APIENTRY WinMain(HINSTANCE hInstance,
                     HINSTANCE hPrevInstance,
                     LPTSTR    lpCmdLine,
                     int       nCmdShow)
{
    hInst = hInstance;
    DialogBox(hInst,MAKEINTRESOURCE(IDD_DIALOG1),0,DlgProc);
    return 0;
}

Автор: korbian 24.4.2007, 08:39
У меня симптомы, к сожалению  smile , не проявились.
по коду:
Нет CloseHandle(hThread) и вместо CreateThread() лучше использовать _beginthreadex()(все равно ведь под VC++ пишешь)

Автор: neosapient 24.4.2007, 17:16
Цитата

У меня симптомы, к сожалению   , не проявились.


Ставишь breakpoint. 

три-пять раз: запускаешь (F5), трассируешь (F11)

Симптомы появятся

Автор: GremlinProg 24.4.2007, 21:02
ну, что тут сказать, проблема довольно распространенная, в вижах она проявляется не так уж сильно, у борланда все намного печальнее: при дебаге дочернего процесса step-by-step замирает через раз на 20-30 секунд, при этом, замирает винда, ощущение такое, что происходит вторжение на уровне ядра, при том, что в вижах нечто подобное отнимает порядка 10-15 секунд. Очевидно, тут дело не в коде. Подозреваю, что дебагеры используют функции ожидания типа WaitForSingleObject, применительно к отлаживаемым потокам, а так как момент синхронизации подразумевает только 2-х участников, то 3-й (дебагер) каким-то образом нарушает эту эдилию. Вижи верно ставят интервал задержки поменьше, но проблема все таки остается...

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

Автор: Aleksandor 25.4.2007, 17:05
А вот http://www.virtualdub.org/blog/pivot/entry.php?id=118 не разгадка?

В двух словах — если у Вас VS 2005 (в статье говорится что та же проблема бывает и с 6.0 и 2003) периодически в момент дебага жутко "тормозит" всю систему — поставьте флажок в:

Control Panel/Regional And Language Options/Language/Details/Advanced/Turn off advanced text services.

И обязательно перегрузитесь!
После этого исчезнет Language Bar, но переключение раскладок работать будет.

Автор: neosapient 25.4.2007, 20:32
Цитата

Control Panel/Regional And Language Options/Language/Details/Advanced/Turn off advanced text services.


Переведу
Пуск -> Настройки -> Панель управления -> Языки и региональные стандарты -> 
вкладка Языки -> Подробнее -> 
вкладка Дополнительно -> поставить галочку Выключить дополнительные текстовые службы

Один минус раскладка клавиатуры отменена (если не перегрузиться), т.е. писать можно только на английском

Вроде помогло  smile 

Автор: Earnest 26.4.2007, 14:47
Aleksandor, очень интересная инфа.
У меня, правда, опция оказалась выключенной, и, насколько помню, никогда ее не включала. Наверное, поэтому с такой проблемой не сталкивалась. 
neosapient тебе должен целый ящик репутаций... 

Автор: GremlinProg 2.5.2007, 14:46
К сожалению, эта опция не решила проблему, по крайней мере в борланде, надо думать дальше...

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)