|
Неадекватный дамп
|
||
|---|---|---|
Участник
Откуда: Омикрон Персей 8
Сообщения: 7 682 |
||
|
Итак,
проблему удалось локализовать и воспроизвести на постоянной основе. 100% в Release сборке и иногда в Debug. Окончательного решения пока не найдено, поскольку логика работы приложения намного сложнее, чем я описал в самом начале и пока есть несколько непонятных моментов с гонкой потоков, но не думаю, что это кому-то интересно в рамках поднятого вопроса о корректности стека. На данный момент понятно следующее: - мешанина из классов в стеке не имеет ничего общего с реальной картиной происходящего и связана только с логикой самих отладчиков и проживающих в них тараканах. Причем не помогает даже полное отключение оптимизации в release сборке - все равно классы в перемешку, и их нужно рассматривать исходя из логики приложения (в моем случае обращения к пулу потоков для конкретного типа серверов), а не из того, что показывает стек. Я уже видел нечто подобное в книге по анализу дампов . Скорее всего мой случай из этой же когорты. - отладчик в Visual Studio 2015, по сравнению с windbg, проигрывает и может скрывать часть информации о вызванных функциях в анализируемом стеке потока, даже при одинаковых pdb. Я не берусь утверждать, что это аксиома, но иногда, в сложных случаях, именно windbg показывает более адекватный стек, нежели чем VS. Сам с этим сталкиваюсь не первый раз и только благодаря windbg удается локализовать проблему гораздо быстрее. Поэтому, если у вас есть postmortem дамп, который вы хотите проанализировать, то не ограничивайтесь только запихиванием его в VS, для сравнения также прогоните его в windbg, можете узнать много нового и более точно локализуете проблему. По сравнению с той версией, которую я использовал в начале анализа проблемы, версия из состава Windows SDK 10.0.15063. 400 позволила увидеть более адекватный стек вызовов, хоть с мешаниной из классов, но, по крайней мере, ведущий к действительному месту падения и его причине - повреждению кучи при попытке повторной очистки ранее удаленного объекта. BUCKET_ID: HEAP_CORRUPTION_ACTIONABLE_BlockNotBusy_DOUBLE_FREE_my_buggy_app!_free_base+1c дамп из WinDbg 10.0.15063.40008 000000eb`2811d550 00007ff8`59950c6a ntdll!KiUserApcDispatch+0x2e 09 000000eb`2811da48 00007ff8`5998b57e ntdll!NtWaitForMultipleObjects+0xa 0a 000000eb`2811da50 00007ff8`5998b0dc ntdll!RtlReportExceptionEx+0x452 0b 000000eb`2811e020 00007ff8`599b1c56 ntdll!RtlReportException+0xbc 0c 000000eb`2811e0b0 00007ff8`59941d86 ntdll!RtlReportCriticalFailure$filt$0+0x33 0d 000000eb`2811e0e0 00007ff8`5995026e ntdll!_C_specific_handler+0x96 0e 000000eb`2811e150 00007ff8`599533fd ntdll!_GSHandlerCheck_SEH+0x76 0f 000000eb`2811e180 00007ff8`59914847 ntdll!RtlpExecuteHandlerForException+0xd 10 000000eb`2811e1b0 00007ff8`59913a6d ntdll!RtlDispatchException+0x197 11 000000eb`2811e880 00007ff8`599b1c00 ntdll!RtlRaiseException+0x18d 12 000000eb`2811f040 00007ff8`599b4e42 ntdll!RtlReportCriticalFailure+0x8c 13 000000eb`2811f150 00007ff8`599b5a40 ntdll!RtlpHeapHandleError+0x12 14 000000eb`2811f180 00007ff8`5996a56f ntdll!RtlpLogHeapFailure+0xa4 15 000000eb`2811f1b0 00007ff7`605c4e20 ntdll! RtlFreeHeap +0x74eff 16 000000eb`2811f250 00007ff7`6057e4ea my_buggy_app![b]_free_base +0x1c [minkernel\crts\ucrt\src\appcrt\heap\free_base.cpp @ 112] 17 000000eb`2811f280 00007ff7`6058d52c my_buggy_app!CPoolTask::`scalar deleting destructor'+0x5a[/b] 18 (Inline Function) --------`-------- my_buggy_app!CCluster<CRdpFarm>::DestroyTaskInternal+0x21 19 000000eb`2811f2b0 00007ff7`6058d5e6 my_buggy_app!CCluster<CRdpFarm>::DeleteTaskGroupInternal+0x5c 1a 000000eb`2811f2e0 00007ff7`6058dbca my_buggy_app!CCluster<CWebFarm>::DeleteTaskGroupInternal+0x66 1b 000000eb`2811f320 00007ff7`60591728 my_buggy_app!CCluster<CWebFarm>::DeleteTaskGroup+0x4a 1c 000000eb`2811f370 00007ff7`6059bfb4 my_buggy_app!CCluster<CWebFarm>::QueryFarm+0x188 1d 000000eb`2811f410 00007ff7`6059beb7 my_buggy_app!CWebCluster::ExecuteRequest+0xc4 1e 000000eb`2811f480 00007ff7`60587ca4 my_buggy_app!CWebCluster::EnumApplications+0x27 1f 000000eb`2811f4c0 00007ff8`5995242e my_buggy_app!CInternalPool::OnWebTransferTimer+0x1a4 20 000000eb`2811f5a0 00007ff8`599506fa ntdll!KiUserApcDispatch+0x2e 21 000000eb`2811fa98 00007ff8`56b11118 ntdll!NtWaitForSingleObject+0xa 22 000000eb`2811faa0 00007ff7`60588c9b KERNELBASE!WaitForSingleObjectEx+0x94 23 000000eb`2811fb40 00007ff7`6057e563 my_buggy_app!CInternalPool::__sWebTransferTimerThread+0x10b 24 (Inline Function) --------`-------- my_buggy_app!CPoolTask::CallTaskRoutine+0x13 25 000000eb`2811fbb0 00007ff7`6057d5fc my_buggy_app!CPoolTask::Execute+0x63 26 000000eb`2811fbe0 00007ff7`605c1eb4 my_buggy_app!CThreadPool::__sThreadPoolWorker+0x14c 27 (Inline Function) --------`-------- my_buggy_app!invoke_thread_procedure+0xd [minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 91] 28 000000eb`2811fc20 00007ff8`58d713d2 my_buggy_app!thread_start<unsigned int (__cdecl*)(void * __ptr64)>+0x50 [minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 115] 29 000000eb`2811fc50 00007ff8`598d54e4 kernel32!BaseThreadInitThunk+0x22 2a 000000eb`2811fc80 00000000`00000000 ntdll!RtlUserThreadStart+0x34 Дамп отличается от первоначального, но проблема та же самая и происходит в том же самом месте при аналогичных обстоятельствах, так что пусть это никого не смущает. Самое главное здесь - более корректный стек вызовов с указанием точной причины возникшей проблемы, с которой мне и предстоит разбираться в дальнейшем, но это уже тема для другого топика... Всем откликнувшимся спасибо за участие  |
||
| 23.06.2017, 14:21 |
|
|
