Хочу поделиться двумя историями с одинаковым сюжетом, но разными развязками.
Может быть кому то, у кого тоже падает JVM будет полезно
1. Native code вызывается из Явы через JNI. Юнит тест — проходит на ура, приложение (GUI, Swing) крэшится.
Подключаемся через дебагер ddd (это такая оболочка над gdb, ежели кто из яваистов не знает :) ) — видим что падает с длинющим стеком. Выясняем с автором нативной библиотеки, что там они десериализуют через boost (такая библиотека для C++) дерево большой глибины. И там рекурсия.
Возникает идея (не сразу, 3 дня споров и гугления), что при вызове из приложения стек больше и он переполняется. Находим параметер для JVM: -XX:ThreadStackSize=
Работает!
2. Native code вызывается через JNA. Присутствую колбеки обратно в Явы, так как я описывал. Юнит тест бежит, приложение падает!
Опять — запускаем ddd (процесс такой — вызывать дебаг версию библиотеки, чтобы видеть соурсы, запустить приложение из среды для дебага, поставить брекпоинт в яве, когда остановится узнать номер процесса Явы, подключиться к ней из ddd, выставить в нем breakpoints, продолжить исполнение в ddd, продолжить исполнение в Яве — фух!)
Видим, что падает при попытке вызвать Ява-колбек. Как же так?! Я знал, что нельзя чтобы колбек собрался gc и сохранил его в поле класса своего сервиса!
Еще день расследований и выясняется:
наши умельцы создавали в приложении еще один Spring Context.
Т.е.
1. Создавался «правильный» контекст, в нем рождался спринг бин моего сервиса, он регистрировал колбек
2. Создавался «лишний» контекст, в нем рождался еще один бин моего сервиса (он синглетон, но только в рамках одного контекста! В другом конкексте еще один истанс!) и регистрировал свой колбек
3. GC собирал лишний контекст, а с ним и мой сервис, а с ним и колбэк
4. Я вызывал свой сервис (из «правильного» спринг контекста), он вызывал C, тот вызывал колбек. А записан у него был уже собранный мусорщиком колбек из «неправильного» спринг контекста!
5. Крэш!
Убираем лишний контекст — работает!
Может быть кому то, у кого тоже падает JVM будет полезно
1. Native code вызывается из Явы через JNI. Юнит тест — проходит на ура, приложение (GUI, Swing) крэшится.
Подключаемся через дебагер ddd (это такая оболочка над gdb, ежели кто из яваистов не знает :) ) — видим что падает с длинющим стеком. Выясняем с автором нативной библиотеки, что там они десериализуют через boost (такая библиотека для C++) дерево большой глибины. И там рекурсия.
Возникает идея (не сразу, 3 дня споров и гугления), что при вызове из приложения стек больше и он переполняется. Находим параметер для JVM: -XX:ThreadStackSize=
Работает!
2. Native code вызывается через JNA. Присутствую колбеки обратно в Явы, так как я описывал. Юнит тест бежит, приложение падает!
Опять — запускаем ddd (процесс такой — вызывать дебаг версию библиотеки, чтобы видеть соурсы, запустить приложение из среды для дебага, поставить брекпоинт в яве, когда остановится узнать номер процесса Явы, подключиться к ней из ddd, выставить в нем breakpoints, продолжить исполнение в ddd, продолжить исполнение в Яве — фух!)
Видим, что падает при попытке вызвать Ява-колбек. Как же так?! Я знал, что нельзя чтобы колбек собрался gc и сохранил его в поле класса своего сервиса!
Еще день расследований и выясняется:
наши умельцы создавали в приложении еще один Spring Context.
Т.е.
1. Создавался «правильный» контекст, в нем рождался спринг бин моего сервиса, он регистрировал колбек
2. Создавался «лишний» контекст, в нем рождался еще один бин моего сервиса (он синглетон, но только в рамках одного контекста! В другом конкексте еще один истанс!) и регистрировал свой колбек
3. GC собирал лишний контекст, а с ним и мой сервис, а с ним и колбэк
4. Я вызывал свой сервис (из «правильного» спринг контекста), он вызывал C, тот вызывал колбек. А записан у него был уже собранный мусорщиком колбек из «неправильного» спринг контекста!
5. Крэш!
Убираем лишний контекст — работает!
