ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / C++ [игнор отключен] [закрыт для гостей] / Можно ли узнать из за какого потока было убито приложение?
25 сообщений из 55, страница 2 из 3
  2  все
Можно ли узнать из за какого потока было убито приложение?
    #34302084
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akh
Участник
onstat-Похоже я не прав с последним постом.
Вероятнее всего, что процесс со всеми нитями прибивается целяком,
и перехваты просто не успевают отработать.

Да, наверное, SIGKILL, который нельзя перехватить, срубает сразу всю группу задач.
...
Рейтинг: 0 / 0
02.02.2007, 13:22
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34302136
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akh
Участник
Вообщем, наметилось 3 пути для поиска:
1) С помощью отладчика/трассировщика, который бы сообщал какой поток/в каком месте сейчас ворочается дело.
2) Программным путем. Здесь без шансов, так как прехватить ничего нельзя.
3) Менеджер задач.

Есть мысли?
...
Рейтинг: 0 / 0
02.02.2007, 13:31
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34302154
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akh
Участник
В исходниках ядра по слову "Killed" ничего подходящего не нашел.
...
Рейтинг: 0 / 0
02.02.2007, 13:34
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34302268
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
AkhВ исходниках ядра по слову "Killed" ничего подходящего не нашел.

Killed пишет шелл из которого запущено приложение.
см. предидущие посты.
...
Рейтинг: 0 / 0
02.02.2007, 13:56
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34303596
A. Fig Lee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A. Fig Lee
Участник
чето вы братцы не туда зарулили мне кается..

Сигнал Килл сам по себе не появляется, ето ответ на чтото.

Короче, добавьте сигнал хендлер на SIGSEGV и прочие сигналы которые валят программу.
...
Рейтинг: 0 / 0
02.02.2007, 19:52
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34305580
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akh
Участник
Действительно сингнал SIGSEGV генерится, но

Код: plaintext
1.
2.
3.
    pid=wait(&status);
//и
    pid=waitpid(- 1 , &status, WUNTRACED);

генерит ошибку об отсутсвии дочерних процессов.
...
Рейтинг: 0 / 0
05.02.2007, 10:35
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34307563
A. Fig Lee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A. Fig Lee
Участник
AkhДействительно сингнал SIGSEGV генерится, но

Код: plaintext
1.
2.
3.
    pid=wait(&status);
//и
    pid=waitpid(- 1 , &status, WUNTRACED);

генерит ошибку об отсутсвии дочерних процессов.

а они при чем? Надо в самой программе ловить в хендлере
...
Рейтинг: 0 / 0
05.02.2007, 19:29
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34308176
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akh
Участник
А я что делаю?

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
void *f(void *) {
    char *p= 0 ;
    char buf[ 2 ];
    int bufLen= 1024 ;

    printf("Child pid=%d\n", getpid());
    for (int i= 0  ; i< 100  ; i++) {
        p = (char*)(i* 1245 + 1245 );
        printf("read from memory %p\n", p);
        memcpy(buf, p, bufLen);
        sleep( 1 );
    };

    return NULL;
};

void fsig(int sig) {
    int pid;
    int status;

    printf("Signal %d\n", sig);
    pid=wait(&status);
//    pid=waitpid(-1, &status, WUNTRACED);

    if (pid!=- 1 ) {
        printf("%d(pid) exited.\n", pid);

        if (WIFEXITED(status)) {
            printf("syccess witch return code %d\n", WEXITSTATUS(status));
            exit (- 1 );
        }

        if (WIFSIGNALED(status)) {
            printf("child is killed by signal %d\n", WTERMSIG(status));
            exit (- 1 );
        }

        if (WIFSTOPPED(status)) {
            printf("child is stopped by signal %d\n", WSTOPSIG(status));
            exit (- 1 );
        }
    } else {
        int err=errno;
        printf("wait returned error %d\n", errno);
        printf("%s\n", strerror(err));
        exit (- 1 );
    }


    exit (- 1 );
}

int main () {
    printf("Main pid=%d\n", getpid());

    if (SIG_ERR==signal(SIGCHLD, fsig)) {
        printf("Signal error!\n");
        exit(- 1 );
    };
    if (SIG_ERR==signal(SIGSEGV, fsig)) {
        printf("Signal error!\n");
        exit(- 1 );
    };

    pthread_t t;
    pthread_attr_t              attr;
    struct sched_param  sp;
    pthread_attr_init(&attr);

    pthread_attr_getschedparam(&attr, &sp);
    pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM);
    pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
    sp.sched_priority = sched_get_priority_max(SCHED_FIFO);
    pthread_attr_setschedparam(&attr, &sp);
    pthread_create(&t, &attr, f, NULL);

    printf("main slepping.\n");
    sleep( 10 );
    printf("main returning.\n");

    return  0 ;
}
...
Рейтинг: 0 / 0
06.02.2007, 09:46
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34308324
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
A. Fig Lee
а они при чем? Надо в самой программе ловить в хендлере



Имется ввиду что это

Akh
Код: plaintext
1.
2.
3.
4.
5.
    if (SIG_ERR==signal(SIGSEGV, fsig)) {
        printf("Signal error!\n");
        exit(- 1 );
    };


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

з.ы. Но ИМХО поймать конкретное место всеравно будет тяжело.
...
Рейтинг: 0 / 0
06.02.2007, 10:28
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34308424
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akh
Участник
Проведенные опыты показали, что где бы я не регестрил обработчик на SIGSEGV, он одинаково вызывается:
1) С pid дочернего процесса.
2) wait возвращает ошибку, что нет дочернего процесса.

Поэтому, мне кажется, логично сделать следующие выводы:
1) Обработчик сигнала регистрируется в рамках группы задач. По крайней мере SIGSEGV.
2) Обработчик вызывается при возникновении сигнала в окружении задачи, к которой пришел сигнал. Для всех сигналов.

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

Верно?
...
Рейтинг: 0 / 0
06.02.2007, 10:52
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34308701
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
AkhПроведенные опыты показали, что где бы я не регестрил обработчик на SIGSEGV, он одинаково вызывается:
1) С pid дочернего процесса.
2) wait возвращает ошибку, что нет дочернего процесса.

Поэтому, мне кажется, логично сделать следующие выводы:
1) Обработчик сигнала регистрируется в рамках группы задач. По крайней мере SIGSEGV.
2) Обработчик вызывается при возникновении сигнала в окружении задачи, к которой пришел сигнал. Для всех сигналов.

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

Верно?

Я толькочто глянул сюда

Там написано:

Код: plaintext
автор
Thread operations include thread creation, termination, synchronization (joins,blocking), scheduling, data management and process interaction.
A thread does not maintain a list of created threads, nor does it know the thread that created it.
All threads within a process share the same address space.
Threads in the same process share:
Process instructions
Most data
open files (descriptors)
[ i]signals and signal handlers
current working directory
User and group id
Each thread has a unique:
Thread ID
set of registers, stack pointer
stack for local variables, return addresses
signal mask
priority
Return value: errno
pthread functions return "0" if OK.

Исходя из этого определить нить которая ведет себя неправильно путем отлова сигналов,
возможно при использовании маскирования сигналов во всех нитях кроме одной
(потенциально проблемной).

Думаю это всеравно тупиковый путь.
ИМХО ловить нужно не нить, а функцию где это происходит.
...
Рейтинг: 0 / 0
06.02.2007, 11:53
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34308807
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akh
Участник
onstat-...
Исходя из этого определить нить которая ведет себя неправильно путем отлова сигналов,
возможно при использовании маскирования сигналов во всех нитях кроме одной
(потенциально проблемной).

Думаю это всеравно тупиковый путь.
ИМХО ловить нужно не нить, а функцию где это происходит.

Что за маскирование? Не встречал. Какие функции помогут для понимания?

Отловить функцию сложнее, и я даже не предствляю как. Где увереность, что в этот момент другой поток не вызвал критическую ситуацию?

А что на счет того, что обработчик вышел с pid-ом, вызвавшего критическую ситуацию, потока?
...
Рейтинг: 0 / 0
06.02.2007, 12:16
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34309042
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
Akh

Что за маскирование? Не встречал. Какие функции помогут для понимания?


sigaction, sigprocmask, sigpending, sigsuspend - POSIX signal handling functions

Akh
Отловить функцию сложнее, и я даже не предствляю как. Где увереность, что в этот момент другой поток не вызвал критическую ситуацию?


Давай двигаться от простого к сложному и от общего к часному.
Поверь это позволит очень сократить время на отладку кода.


man 2 signal
NOTES
The effects of this call in a multi-threaded process are unspecified.
The routine handler must be very careful, since processing elsewhere
was interrupted at some arbitrary point. POSIX has the concept of
"safe function". If a signal interrupts an unsafe function, and han-
dler calls an unsafe function, then the behavior is undefined. Safe
functions are listed explicitly in the various standards. The POSIX
1003.1-2003 list is
_Exit() _exit() abort() accept() access() aio_error() aio_return()
aio_suspend() alarm() bind() cfgetispeed() cfgetospeed() cfsetispeed()
cfsetospeed() chdir() chmod() chown() clock_gettime() close() con-
nect() creat() dup() dup2() execle() execve() fchmod() fchown()
fcntl() fdatasync() fork() fpathconf() fstat() fsync() ftruncate()
getegid() geteuid() getgid() getgroups() getpeername() getpgrp() get-
pid() getppid() getsockname() getsockopt() getuid() kill() link() lis-
ten() lseek() lstat() mkdir() mkfifo() open() pathconf() pause()
pipe() poll() posix_trace_event() pselect() raise() read() readlink()
recv() recvfrom() recvmsg() rename() rmdir() select() sem_post()
send() sendmsg() sendto() setgid() setpgid() setsid() setsockopt()
setuid() shutdown() sigaction() sigaddset() sigdelset() sigemptyset()
sigfillset() sigismember() signal() sigpause() sigpending()
sigprocmask() sigqueue() sigset() sigsuspend() sleep() socket() socketpair()
stat() symlink() sysconf() tcdrain() tcflow() tcflush() tcgetattr()
tcgetpgrp() tcsendbreak() tcsetattr() tcsetpgrp() time()
timer_getoverrun() timer_gettime() timer_settime() times() umask()
uname() unlink() utime() wait() waitpid() write().

According to POSIX, the behaviour of a process is undefined after it
ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by
the kill(2) or the raise(3) functions. Integer division by zero has
undefined result. On some architectures it will generate a SIGFPE
signal. (Also dividing the most negative integer by -1 may generate
SIGFPE.) Ignoring this signal might lead to an endless loop.


Особое внимание нужно обратить на использование защищенных функций при работе с потоками и строками.
...
Рейтинг: 0 / 0
06.02.2007, 12:58
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34310496
A. Fig Lee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A. Fig Lee
Участник
бесполезно ето, как онстат говорит. надо месседжи дебаговые в функции вставлять.
...
Рейтинг: 0 / 0
06.02.2007, 18:59
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34311257
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akh
Участник
A. Fig Leeбесполезно ето, как онстат говорит. надо месседжи дебаговые в функции вставлять.

Это трудоемкий процесс - раз.
Среди десятка мессаджей (десяток потоков) надо будет искать после которого произошла ошибка. Это два.

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

А что вы думаете на счет того, что обработчик вышел с pid-ом, вызвавшего критическую ситуацию, потока?
...
Рейтинг: 0 / 0
07.02.2007, 09:44
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34311447
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
Akh

А что вы думаете на счет того, что обработчик вышел с pid-ом, вызвавшего критическую ситуацию, потока?

Не обязательно,
например: указатель мог испортить один, а упал тот, который потом по нему обратился.
...
Рейтинг: 0 / 0
07.02.2007, 10:30
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34311678
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akh
Участник
onstat- Akh

А что вы думаете на счет того, что обработчик вышел с pid-ом, вызвавшего критическую ситуацию, потока?

Не обязательно,
например: указатель мог испортить один, а упал тот, который потом по нему обратился.

Ну, тут уже ничего не поделаешь... Важно, быть уверенным, что упал именно этот.
...
Рейтинг: 0 / 0
07.02.2007, 11:11
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34312151
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
Akh onstat- Akh

А что вы думаете на счет того, что обработчик вышел с pid-ом, вызвавшего критическую ситуацию, потока?

Не обязательно,
например: указатель мог испортить один, а упал тот, который потом по нему обратился.

Ну, тут уже ничего не поделаешь... Важно, быть уверенным, что упал именно этот.

Если с маскированием сигналов ничего не получилось, то есть еще одна идея.

Завести поток арбитража, который сериализует выполнение нитей через мутексы, и ведет протокол очередности выполнения.


Если последовательное выполнение к падению не приводит, то нужно искать багу или проблему дизайна во взаимодейтсвии нитей.

Если приводит все будет понятно, кто последним запущен тот и виноват.
...
Рейтинг: 0 / 0
07.02.2007, 12:31
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34313677
A. Fig Lee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A. Fig Lee
Участник
Akh A. Fig Leeбесполезно ето, как онстат говорит. надо месседжи дебаговые в функции вставлять.

Это трудоемкий процесс - раз.
Среди десятка мессаджей (десяток потоков) надо будет искать после которого произошла ошибка. Это два.

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

А что вы думаете на счет того, что обработчик вышел с pid-ом, вызвавшего критическую ситуацию, потока?

а смысл? если каждый поток исполняет тот же код? что ето даст?
...
Рейтинг: 0 / 0
07.02.2007, 17:57
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34313778
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
A. Fig Lee Akh A. Fig Leeбесполезно ето, как онстат говорит. надо месседжи дебаговые в функции вставлять.

Это трудоемкий процесс - раз.
Среди десятка мессаджей (десяток потоков) надо будет искать после которого произошла ошибка. Это два.

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

А что вы думаете на счет того, что обработчик вышел с pid-ом, вызвавшего критическую ситуацию, потока?

а смысл? если каждый поток исполняет тот же код? что ето даст?

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

з.ы. Мы сейчас начали обсуждать наличие кошки в темной комнате, даже не присутствуя там.
...
Рейтинг: 0 / 0
07.02.2007, 18:26
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34313790
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
onstat- A. Fig Lee Akh A. Fig Leeбесполезно ето, как онстат говорит. надо месседжи дебаговые в функции вставлять.

Это трудоемкий процесс - раз.
Среди десятка мессаджей (десяток потоков) надо будет искать после которого произошла ошибка. Это два.

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

А что вы думаете на счет того, что обработчик вышел с pid-ом, вызвавшего критическую ситуацию, потока?

а смысл? если каждый поток исполняет тот же код? что ето даст?

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

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

Прошу прощения, не заметил что это ответ не мне.
Устал устал уже видимо за день.
...
Рейтинг: 0 / 0
07.02.2007, 18:29
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34314784
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akh
Участник
A. Fig Lee Akh A. Fig Leeбесполезно ето, как онстат говорит. надо месседжи дебаговые в функции вставлять.

Это трудоемкий процесс - раз.
Среди десятка мессаджей (десяток потоков) надо будет искать после которого произошла ошибка. Это два.

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

А что вы думаете на счет того, что обработчик вышел с pid-ом, вызвавшего критическую ситуацию, потока?

а смысл? если каждый поток исполняет тот же код? что ето даст?

У меня обычная схема - взаимодействие классов, некоторые из которых имеют свои потоки. Стековая архитектура (по типу TCP/IP). Код выполняется разный, и кто-то (поток) может спороть ерунду. Если опредилить, кто это сделал, будет проще начать искать ошибку (функцию, потом действие, потом анализ ситуации, а потом уже анализ причин).
...
Рейтинг: 0 / 0
08.02.2007, 10:03
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34314801
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akh
Участник
onstat-Это даст возможность локализовать проблему,
во взаимодействии нитей ( нити портят данные паралельной записью),
или все же проблема не зависит от нитей ( появляейтся и при последовательном выполнении).

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

onstat-з.ы. Мы сейчас начали обсуждать наличие кошки в темной комнате, даже не присутствуя там.

Я хотел узнать, какой поток вызывает аварийное завершение приложения.
...
Рейтинг: 0 / 0
08.02.2007, 10:08
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34315178
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
Akh onstat-Это даст возможность локализовать проблему,
во взаимодействии нитей ( нити портят данные паралельной записью),
или все же проблема не зависит от нитей ( появляейтся и при последовательном выполнении).

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

onstat-з.ы. Мы сейчас начали обсуждать наличие кошки в темной комнате, даже не присутствуя там.

Я хотел узнать, какой поток вызывает аварийное завершение приложения.

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
$gdb  program_name
GNU gdb Red Hat Linux ( 6 . 3 . 0 . 0 - 0 .31rh)
Copyright  2004  Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db lib
rary "/lib/libthread_db.so.1".

(gdb) run

в результате должно получиться приблизительно следующее:

Код: plaintext
1.
2.
Program received signal SIGSEGV, Segmentation fault.
0x0017bcee in dummy()  from .........

Дальше будем смотреть.

з.ы. Это должно быть первым дествием после того как программа падает во время отладки.
...
Рейтинг: 0 / 0
08.02.2007, 11:49
| Ответить | Цитировать | Написать  
Можно ли узнать из за какого потока было убито приложение?
    #34315478
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akh
Участник
onstat-Дабы приоткрыть дверь в темную комнату, опубликуй пожалуйста здесь
вывод , который появится на экране после выполнения:

Нет сейчас никакого приложения, которое падает. Излечил в течении суток с момента задания вопроса. Сейчас интересует подход/средства по поставленному вопросу.
...
Рейтинг: 0 / 0
08.02.2007, 12:47
| Ответить | Цитировать | Написать  
25 сообщений из 55, страница 2 из 3
  2  все
Форумы / C++ [игнор отключен] [закрыт для гостей] / Можно ли узнать из за какого потока было убито приложение?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=57&startmsg=34302084&tid=2029477]:
 0ms
get settings:
 5ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 54ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 60ms
get tp. blocked users:
 1ms
others: 232ms
total:  383ms
созд. / загр.: 383ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]