Как отладить ошибочный стек вызовов в Visual Studio

Я работаю с огромным классом из 3-й библиотеки, вот выдержка из соответствующих вещей:

class SomeClass {
// ...
public:
// ...
virtual int SetTableSize(unsigned int uiTableID, int iSize);
// ...
protected:
// ...
virtual int Set_0xB0_0x23_IsoTableData(unsigned char* ucData, int iLen);
// ...
};

Мое приложение разрывается с нарушением доступа к памяти. Самый верхний элемент в стеке вызовов — это строка кода в реализации Set_0xB0_0x23_IsoTableDataвторой элемент — это строка кода, подобная этой:

someClassInstance.SetTableSize(2, 400);

В режиме отладки, ucData имеет значение 0x00000002так что это действительно выглядит вместо вызова реализации SetTableSize, что должно происходить в соответствии с кодом, Set_0xB0_0x23_IsoTableData вызывается с указанными параметрами — что, очевидно, приводит к ошибке, поскольку указатель недействителен.

Я уже потратил много времени на выяснение того, что здесь происходит. Я компилирую тот же код в другом приложении с GCC на Linux, и он работает там. Это ошибка компилятора Visual Studio? Я не получаю никаких предупреждений при компиляции этого кода.

Невозможно создать минимальный рабочий пример для воспроизведения ошибки — по крайней мере, пока я не выясню причину, по которой это происходит. SomeClass заголовок имеет довольно много #ifdefв ней, поэтому первое, что я подумал, было то, что определения препроцессора были разными при компиляции модуля, содержащего SomeClass чем при компиляции моего кода вызова. Тем не менее, я дважды проверил и определения совпадают.

Так что я хочу спросить в основном:

  • При каких условиях вызов виртуального метода может вызвать реализацию другого виртуального метода? (речь идет не о наследовании — оба метода определены в одном классе и даже не имеют общей подписи и имеют разную видимость)
  • Как я могу отладить такую ​​ошибку? Можно ли просмотреть вектор диспетчеризации экземпляра класса в Visual Studio?

3

Решение

Мой стандартный ответ для такого рода проблем: перестроить все. В некоторых случаях это так же просто / глупо (по крайней мере, для Visual Studio).

Если ошибка все еще остается, то я бы отладил: Запустите код так далеко, как вы можете сказать, что «это не могло произойти к настоящему времени». Затем отлаживайте шаг за шагом, строку за строкой и внимательно следите за стеком вызовов.

И нет, это не весело.

0

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]