Программа падает в CThreadLocalObject::GetData.

[ezus]

MS VC++ 6  + MFC.
Работа с диалогами.
Огромный комплекс. После внесения некоторых изменений программа начала падать в процессе работы.

Стек:

CThreadLocalObject::GetData(CNoTrackObject * (void)* 0x5f48efb0 CThreadLocal<_AFX_THREAD_STATE>::CreateObject(void)) line 388 + 7 bytes
CThreadLocal<_AFX_THREAD_STATE>::GetData() line 173 + 13 bytes
CThreadLocal<_AFX_THREAD_STATE>::operator->() line 185 + 15 bytes
AFX_MAINTAIN_STATE2::AFX_MAINTAIN_STATE2(AFX_MODULE_STATE * 0x00152148) line 46 + 10 bytes
AfxWndProcBase(HWND__ * 0x00550bcc, unsigned int 13, unsigned int 32, long 201396) line 219 + 19 bytes
USER32! 7e418734()
USER32! 7e418816()
USER32! 7e42a013()
USER32! 7e42a998()
USKIN! 015e829e()

ЧТо это вообще может значить.
Я с тредами не работаю.

Спасибо за любые слова, мысли, идеи.
 

[baldr]

Судя по AfxWndProcBase() - идет обработка сообщения окну.. В MFC, возможно, оно асинхронное - оттуда и треды.. Вообще, я думаю, мало что можно сказать по приведенным данным..

[lapulya]

Что-то у меня большие сомнения, что реализация работы с UI в MFC асинхронная... Ну пушистый придет, может что-нить скажет. А вообще, согласен с baldr, очень мало данных для диагностики.

[ezus]

Я прекрасно понимаю, что данных не достаточно.
Что я НЕ понимаю - так это Какие данные могут понадобиться - Куда смотреть???

[Вад]

Смотреть на line 388 из первой строчки колл-стека. И текущие значения локальных переменных в watch-е на момент останова. Смотреть, что именно вызвало падение, и разбираться, что к этому привело.

[ezus]

Как видно из стека - это чисто системные замарочки. Я их не вызывал и, к сожалению, не имеют представления зачем они и что делают. Могу только чуть-чуть догадываться, но не на уровне классов-объектов-функций, и тем более на уровне значений их внутренних переменных.

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

[Джон]

Какие данные могут понадобиться - Куда смотреть???

Нууу в силу:

После внесения некоторых изменений программа начала падать в процессе работы.

Начни хотя бы с этих самых изменений. Где они были сделаны? Что было сделано? Падает ли программа, если вернутся к версии ДО изменений? Ну и тп.

[ezus]

Начни хотя бы с этих самых изменений. Где они были сделаны? Что было сделано? Падает ли программа, если вернутся к версии ДО изменений? Ну и тп.

Этот путь я оттягиваю до последнего по 2 причинам.
1. В ожидании выпуска релиза я возился без сохранения, поэтому, накопилось наверняка не связанных с проблемой, изменений и не хотелось бы их терять и повторять.
2. Все-таки хотелось бы понять в чем дело - хотя бы во имя будущих проблем.

Откатиться к исходной позиции я всегда успею, но это противно и трудоемко.

[Джон]

Значица так. Все сообщения об ошибках ни к чему не приведут, тк падает что-то в глубинах MFC объектов, к которым, как ты правильно заметил, ты не имеешь никакого отношения. Мой опыт  с MFC показывает, что такие падения можно спровоцировать очень банальными действиями, как-то: забыв (или удалив) стиль, вызов инициаллизирующей ф-ции, бардак в ресурсах, пролинковав неподходящую dll и тд и тп.

Поэтому в данной ситуации проще и надёжней восстановить сценарий изменений.

Ты можешь хотя бы описать что происходит с программой в момент падения, какие объекты в этот момент активны (окна, контроллы и тд)? Какие действия совершаются (нажимается кнопка, открывается комбобокс и тп)?

Иначе на твой вопрос: "Что это значит?", можно ответить лишь: "Всё что угодно" и это будет правда.

[Алексей++]

я бы, как и Джон, восстановил предыдущую, рабочую версию и убедился, что она работает. Потом внёс одно изменение и убедился, что оно работает. И так, пока не упадёт. Место локализовано!

Теперь берём самую последнюю версию (косячную), забиваем проблемное место и убеждаемся, что всё работает. Далее - по обстоятельствам

[ezus]

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

А выглядит это так.
По сути это реализация "черного входа" в программу для отслеживания ее внутреннего состояния.
В стандартном "ОК" стандартного диалога "Abuot" вызывается другой диалог - параметры и режимы отладочной печати. Эту операцию можно выполнить практически в любое время.
Все работало.
Я добавил к существующим 3 десяткам check-boxs еще штук пять - вроде все работает. Затем попытался из того диалога вызвать его снова, понял, что что-то напартачил - отказался от этой глупости, вроде все почистил - и вот тут она начала падать.
Делает она это так: запуск программы - загрузка информации - Abuot - ОК - этот диалог - ОК - снова  этот диалог - ОК - вычисления  - снова  вызов этого диалог и во тут - Abort.
Я пока даже не отследил через отладку или печать, где это в коде, а из стека ничего не выжмешь.

Ну ладно. Путь, хоть и противный, но ясный.
Еще раз всем Спасибо.

[Алексей++]

ezus, то есть ты с модального диалога (About) вызываешь немодальный диалог (и, скорее всего, делаешь для него родителем этот About). А когда закрываешь About, немодальный диалог остаётся и ссылается на кривого родителя - вуаля

[Алексей++]

ezus, есть другой путь, менее противный: копируешь проект. Потом отрезаешь всё, что к ошибке не относится. Остаётся небольшой проектик с ошибкой. А даже прикрепить его можно будет сюда )

[ezus]

ezus, то есть ты с модального диалога (About) вызываешь немодальный диалог (и, скорее всего, делаешь для него родителем этот About). А когда закрываешь About, немодальный диалог остаётся и ссылается на кривого родителя - вуаля

Нет, из About я вызываю классический модальный, и About не закрыть пока не выйти из диалога.

ezus, есть другой путь, менее противный: копируешь проект. Потом отрезаешь всё, что к ошибке не относится. Остаётся небольшой проектик с ошибкой. А даже прикрепить его можно будет сюда )

К сожалению это не реально. Только основная программа содержит сотню файлов и классов, а кроме нее есть еще два десятка DLL и LIB/

[Алексей++]

>>К сожалению это не реально
нереально отрезать ? Как это так

[ezus]

Там так много отрезать, что ....

[Алексей++]

Не понимаю трудность отрезания. Это даже прикольно - распутыватешь клубок, в котором где-то иголка засела

[Джон]

ezus, тебе могут помочь только соблюдение элементарных правил. Но это в будущем. А в сложившейся ситуации... Ну попробуй понавтыкать до и после вызова ф-ций дебажные сообщения. Типа "начало...1" "конец 1", "начало...2" "конец 2" и тд

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

[ezus]

Ну попробуй понавтыкать до и после вызова ф-ций дебажные сообщения. Типа "начало...1" "конец 1", "начало...2" "конец 2" и тд

Это понятно. Просто я гонял программу в релизе, а система отладочной печати работает только в дебаге.
Я, конечно, нащупаю это место.
Сама ситуация неуправляемости противна - вот я и обратился к Вам. Вдруг у кого-нибудь есть идеи из личного опыта. А как выбираться из этой дряни в общем-то понятно (на данный момент).

Еще раз всем спасибо.

[Джон]

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

Нифига подобного! Она работает при любой компиляции, если только будет вызвана. Бывает скажем ситуация, когда в дебаге всё работает, а вот в релизе не хочет (или просто, необходимо выводить некие сообщения). В таких случаях вызывай OutputDebugString в нужном месте и будте тебе отладочная печать в релизе.

[Джон]

Сама ситуация неуправляемости противна - вот я и обратился к Вам.

Нуууу скажем так, поздно обратился.

Элементарные правила, о которых я упоминал это:

1. Модульные тесты (unit tests)
2. Управление версиями (их куча выбирай любую, я юзаю SVN)
3. Постоянное компилирование и сборка проекта при изменениях кода на образцовом компе (сервере) - continuous building. Для студии - msbuild.
4. Автоматизированные тесты готовой программы.

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

[ezus]

Джон
Под неуправляемостью я понимал сбой на системном уровне, т.е. невозможность разбираться в самом месте сбоя - только косвенно.
Почему не сохранял версии - тоже описал - ждал выпуска релиза, а пока работал на своем компе с системой отладочной печати, моей личной, поэтому откат не будет болезненным, просто жалко потерять то, что сделал.
А остальные советы касаются управления проектами, это немножко не то, что я спрашивал.
У нас есть система управления версиями, независимый сервер для полной компиляции, есть отдельные тесты.
Систему в целом тестировать сложно, т.к. она принципиально диалоговая. Да и просто старая - в ней есть коды еще с ДОСовского С, с фарами - 20 лет.

Поэтому мой вопрос был не "Как программировать", а "Что может означать представленный стек, и Что из него можно выжать?"

[Джон]

Да всё я прекрасно понял. Ибо сам сталкиваюсь с подобным сплошь и рядом. И работаю я не один, а в команде. А это только увеличивает вероятность поулчения таких проблем. Один там изменил, другой тут подкрутил и ага. А бывает и так. Вот мыло получил позавчера. А там вот такое сообщение об ошибке:

И что? Это стандартный из файл MFC, я его не подгонял, assertion ни о чём не говорит. И всё. Посылаю клиента нах и советую руки мыть перед установкой проги. Почему? Да потому что это только на его компе такая херня, а на остальных 100 000 всё в порядке. А реально - может он где-то dll-ку забыл, или старую оставил. Или ещё что. Причин может быть куча. Чтобы это выснить уходит неделя. Кто её оплатит? Клиент? Для него это ошибка проги. Шеф? Для него это ошибка пользователя с корявыми ручками. НО! Иногда бывают ОЧЕНЬ ВАЖНЫЕ клиенты, что наши клиенты говорят: делайте, башляем.
И что? Опять неделю на это гробить? Вот тут все указаные мероприятия и помогают.

Понимаешь, то, что ты называешь сбой на системном уровне, на самом деле результат совсем другой причины. Твою попытку можно сравнить с изучением атмосферного электричества, анализируя исключительно гром. Ты собираешь все параметры: скорость, частоту, силу. А толку?
Да система вылетела в каком-то месте, кто-то (слава Богу! а может и наоборот) удосужился (а может просто забыл удалить) вставить парочку трейсов и ага. Уже головы ломаются. Поэтому представленный тобой стек - на самом деле не стек, а просто горстка сообщений дошедших до приёмника. Его можно анализировать только осознанно, специально создавая условия для его генерации. А так...

Я понимаю, что ты "не то спрашивал". Но, судя по тому, что ты эти правила не выполняешь (причины твои - не причины, а отмазка, если хочешь могу подробней, а пока не буду), всё-таки советую тебе на будущее, чтобы сохранить и нервы, и время ими всегда пользоваться и дай Бог, чтобы тебе никогда не понадобилось ни откатывать версии, ни прогонять модульные тесты больше одного раза. А уж тем более, если ты работаешь с большими сложными старыми обновляемыми проектами. Про управление проектами кстати не было речи. Так же как и о советах "как программировать". Все указанные мероприятия с программированием не связаны. Может ты что-то не так понял?

[ezus]

Джон
Чтобы было более понятно без лишних слов: я всю свою жизнь пишу программы, а первую программу я написал в 1969 году. Просто к С++ явернулся только 2 года назад после 20-ти летнего перерыва.
Поэтому все что Вы посоветовали, мне известно. Но жизнь штука сложная, и в ней ситуации возникают разные.

Я понимаю. что С++ опыта мне не достает, а кто-то может быть уже сталкивался с похожей картинкой, или лучше меня понимает причем тут threads в программе, которая сама их не порождает. Вот я и задал свой вопрос. Фактически он означал: Кто-нибудь еще встречал такой стек? И если да, то он понял что это значит или нет? И как он выходил из данной ситуации?
И к сожалению, я получил ответ, которого ожидал.

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

И все равно спасибо.

Кстати может вы подскажите в каких случаях после завершения аппликации в списке процессов остается процесс с тем же именем?

[Dimka]

По-моему, все беды от нежелания вникать в суть дела. Даже на своём уровне разработки, не влезая в глубины MFC.

А выглядит это так.
По сути это реализация "черного входа" в программу для отслеживания ее внутреннего состояния.
В стандартном "ОК" стандартного диалога "Abuot" вызывается другой диалог - параметры и режимы отладочной печати. Эту операцию можно выполнить практически в любое время.
Все работало.
Я добавил к существующим 3 десяткам check-boxs еще штук пять - вроде все работает. Затем попытался из того диалога вызвать его снова, понял, что что-то напартачил - отказался от этой глупости, вроде все почистил - и вот тут она начала падать.
Делает она это так: запуск программы - загрузка информации - Abuot - ОК - этот диалог - ОК - снова  этот диалог - ОК - вычисления  - снова  вызов этого диалог и во тут - Abort.
Я пока даже не отследил через отладку или печать, где это в коде, а из стека ничего не выжмешь.

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

[ezus]

Еще  раз всем спасибо.
Исходная проблема потеряла свою акктуальность.
Откатил - провел изменения по новой - все работает (пока).
Разбираться не стал - скорее всего какая-нибудь бредовая описка и все летит нафиг.
Жалко время.

Разве что, кто-нибуть сможет прокомментировать роль этого "CThreadLocalObject" в жизни MFC?
Когда и кем он порождается и что делает?

[Dimka]

Разве что, кто-нибуть сможет прокомментировать роль этого "CThreadLocalObject" в жизни MFC?
Когда и кем он порождается и что делает?

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

Что-то типа:

Код: (C++)

// Структура моих данных
class MyData:
   public CNoTrackObject
{
public:
   // какие-то данные
   int x;
};

// Типа глобальной переменной. На самом деле в каждом потоке автоматически создаётся свой экземпляр, привязанный к контексту потока.
CThreadLocal<MyData> myData;

// Где-то используем.
void f()
{
   myData->x = 3;
   int y = myData->x;
}

[ezus]

Этот класс - предок для CThreadLocal. Насколько я понимаю, последний является контейнером для данных текущего потока,

В моем случае надо понимать, что это главный и единственный поток программы?

[Dimka]

ezus, откуда ж я знаю? Я ж эти 100 файлов и 20 библиотек не видел.

Могу сказать, что внутри этой CThreadLocalObject есть счётчик ссылок со всеми вытекающими из этого факта последствиями. Я бы повнимательнее посмотрел на код, соответствующий открытию окон. При таком порядке (или беспорядке) открытия окон какой-нибудь MFC-шный инициализирующий макрос или функция, могут вызываться несколько раз, что и приводит к обозначенной проблеме.

[ezus]

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

О-О-О-О!!!!!!!  ) Это то, что я искал. Спасибо.
Как я понял из выше сказанного - повторный вызов инициирующих макросов может дать такой эффект?
Если да, тогда понятно, что у меня произошло.
Еше раз спасибо - это то, что мне надо.
Теперь буду спать спокойно . Хотя бы какое-то время.