Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
Когда виртуальная машина Java (JVM) обнаруживает катастрофический отказ в собственном коде, таком как код JNI, записанный разработчиком или когда сама JVM откажет, это напечатает отладочную информацию о катастрофическом отказе. Это сообщение об ошибке обычно будет включать информацию, такую как имя функции, имя библиотеки, имя исходного файла и номер строки, в котором произошла ошибка. (В настоящий момент информация об имени файла и номере строки доступна только доступная на платформах Microsoft Windows.) Для примера сообщения, испускаемого обработчиком ошибок, см. Ошибочный пример JNI.
Информация, предоставленная новым механизмом сообщения об ошибке, позволит разработчикам более легко и эффективно отладит их приложения. Если сообщение об ошибке укажет на проблему в коде JVM непосредственно, то это позволит разработчику представлять более точный и полезный отчет об ошибках.
Иногда механизм сообщения об ошибке не будет в состоянии определить информацию, которая могла бы быть полезной в определении местоположения источника катастрофического отказа. Чтобы вытащить наиболее из обработчика ошибок, разработчики должны знать о следующих инструкциях и ограничениях.
При некоторых обстоятельствах механизм сообщения об ошибке не будет в состоянии определить имена символа. Наиболее распространенная причина этого состоит в том, что двоичный код, который отказал, не был скомпилирован в режиме отладки и поэтому не имеет таблиц символов. Разработчики должны скомпилировать свой код в режиме отладки, чтобы гарантировать, что это содержит необходимую отладочную информацию. В Visual Studio, например, это означает выбирать "Отладку", а не "Выпуск" как режим сборки проекта. При использовании gcc или cc на Linux или на операционной среде Соляриса, скомпилируйте использование параметра командной строки -g.
Даже без отладочной информации в двоичном коде, обработчик ошибок может все еще напечатать имя функции места крушения. Однако, имя функции не могло бы быть корректным, если проблематичная функция не "экспортируется" из динамической библиотеки. На Linux и Солярисе, все функции экспортируются кроме объявленных статичными. На платформах Microsoft Windows никакие функции не экспортируются если явно не объявлено так (использование JNIEXPORT или __declspec(dllexport)).
На Windows 98 и платформах Windows NT, обработчик ошибок использует файл imagehlp.dll системы, чтобы помочь определить имя функции, исходный файл, и номер строки места крушения. (Windows 2000 и Windows ME используют два файла, imagehlp.dll и debughlp.dll, чтобы выполнить эту задачу.) Однако, файл imagehlp.dll в Windows 98 и Windows NT не работает хорошо с двоичным кодом и DLL, сгенерированными Visual Studio 6.0.
Эта проблема может заставить обработчик ошибок генерировать сообщения об ошибках с неправильной информацией об имени функции, исходном файле и номере строки места крушения, хотя другая информация в сообщении об ошибке будет корректна.
