Отладка нарушения прав доступа

Question

Я использую большой фреймворк с закрытым исходным кодом. Я недавно добавил новый объект, и теперь я получаю нарушения прав доступа при выполнении некоторых действий. Тем не менее, они происходят при вызовах изнутри фреймворка, поэтому я не знаю, что я реализовал неправильно, так как я не получаю стек вызовов.

О нарушении сообщается в функции _CRTIMP PFLS_GETVALUE_FUNCTION __cdecl __set_flsgetvalue(), определенной в файле CRT tidtable.c. Конкретная строка PFLS_GETVALUE_FUNCTION flsGetValue = FLS_GETVALUE;. Я не уверен, но я думаю, что это связано с указателями на функции?

Сообщение об ошибке Unhandled exception at 0x0000007a in fmwk.exe: 0xC0000005: Access violation reading location 0x0000007a.. Моя интерпретация заключается в том, что он пытается получить доступ к объекту со смещением 0x7a, но ему обычно дается нулевой указатель. Это правильно? Если это так, есть ли способ найти то, что соответствует этому смещению?

Ниже находится стек вызовов:

0000007a()  
fmwk.dll!100f2630()     
[Frames below may be incorrect and/or missing, no symbols loaded for fmwk.dll]  

<lots of framework and windows dlls>

fmwk.exe!00402ef4()     
msvcr100.dll!__set_flsgetvalue()  Line 145 + 0xc bytes  C
msvcr100.dll!_getptd_noexit()  Line 498 + 0x7 bytes C
msvcr100.dll!_getptd()  Line 523 + 0x5 bytes    C
msvcr100.dll!_LocaleUpdate::_LocaleUpdate(localeinfo_struct * plocinfo=0x00000000)  Line 243 + 0x5 bytes    C++
msvcr100.dll!x_ismbbtype_l(localeinfo_struct * plocinfo=0x00000000, unsigned int tst=0, int cmask=1386664, int kmask=1414714)  Line 219 C++
msvcr100.dll!_ismbblead(unsigned int tst=0)  Line 172 + 0xe bytes   C++
fmwk.exe!004010a0()     
fmwk.exe!00404d61()     
kernel32.dll!7c817077()     

Answer 1

Используйте Application Verifier для отладки этого нарушения доступа. Он должен остановить выполнение раньше, когда случится что-то плохое с лучшим стеком вызовов, чем этот.

Похоже, что вы где-то разыменовали NULL-указатель, но программа не вылетала сразу, так как это неопределенное поведение, продолжала выполняться и чуть позже вылетала со странным стеком вызовов.

Answer 2

Относительно вашего вопроса: Да, доступ к 0x7A подозрительно выглядит как разыменование нулевого указателя со смещением 0x7a.(Хотя это может быть что-то вроде разыменования 0x20 со смещением 0x5a).

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