странный ассемблер ... это может быть причиной сбоя моих приложений?

Question

У меня есть программа на родном C ++ под Windows, которая использует VB6 DLL.Приложение C ++ аварийно завершает работу с ошибкой «In-точный результат с плавающей запятой» при использовании этой DLL для определенного действия.

Когда я вхожу в отладку и выполняю просмотр ассемблера, я получаю следующую строку:

75A0FB7C  je          759E8797 

Когда вы наводите курсор мыши на самый правый адрес, появляется всплывающая подсказка со следующим текстом:

1.#INF0000000000

Может быть, поэтому я получаю эту ошибку?

Кто-нибудь знает, почему этовызвано?Запуск этой библиотеки VB6 под IDE VB6 не приводит к такой ошибке ...

Answer 1

Нет, это не имеет ничего общего с FPU.Среда выполнения VB6 не использует это исключение с плавающей запятой для реализации собственной обработки исключений.Выражение On Error, я уверен, что вы с ним знакомы.

Почему, черт возьми, они решили повторно использовать аппаратный код исключения, для меня всегда было загадкой, что лакомый кусочек теряется за 15 летVisual Basic дизайн.Это не байт, потому что FPU инициализируется средой выполнения VB6 с этим замаскированным исключением.

В любом случае, диагностика состоит в том, что ваш код VB6 дает сбой с необработанным исключением.Чтобы узнать, что происходит, обязательно запустите код из отладчика VB6.Также убедитесь, что вы проверили диалог «Отладка + Исключения», окна «Брошенные» должны быть отключены.Нажмите F5, чтобы исключение было обработано обычным способом.После этого он должен идти kaboom.

Из полезной ссылки MarkJ:

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

Answer 2

Я подозреваю, что отладчик неверно интерпретирует этот адрес как число с плавающей точкой, и это битовое представление оказывается #INF.По крайней мере, в некоторых случаях аппарат x86 будет зависать в операторе с плавающей запятой ПОСЛЕ того, который фактически вызвал проблему.Я думаю, что нам нужно больше контекста, но было ли одно из предыдущих утверждений сравнением с плавающей запятой при подготовке к условному переходу?

Кажется возможным, что программа C ++ выполняет некоторую математику с плавающей запятой, которая устанавливает один из FPрегистры состояния, а затем DLL-библиотека VB6 является просто жертвой того, что FPU находится в нестабильном состоянии при вызове.

Вы точно определили, какие входные данные создают проблему?