Закончились разборки с платформами...

...Windows, Sun Solaris, Linux и MacOS.
Наиболее корректно повела себя MacOS, с помощью которой и удалось локализовать проблему. Изначально же, приложение (собранное из одних и тех же исходников!) устойчиво работало везде, кроме Sun Solaris, где оно --- приложение --- загадочным образом падало.
Исходники были не мои, поэтому поиск "того, не знаю чего" занял несколько дней. Хорошо, что вовремя связался с MacOS.
Проблема оказалась в работе с константными строками. То есть, в коде было написано такое:
char *CONST_NAME = "blah-blah-...";
И, через много мегабайт кода, ---
free(CONST_NAME);
Не спрашивайте, почему так, не я писал. Возможно, там изначально констант и не было.
Windows на такие подставы не реагирует, ибо там строки не помещаются компилятором в неизменяемую секцию данных (если компилятор не может от них избавиться). Известная штука. Linux на это промолчал, думаю, что там можно специальными средствами локализовать проблему (если бы я, скажем, сказал что-то типа CONST_NAME[1] = 'k', то получил бы сигналом в лоб, а так...). MacOS честно бросила в консоль сообщение, что есть проблемы с вызовом free(). И только Sun Solaris молча падала, причем падение происходило уже после возвращения из нативного кода в Java, что только запутывало ситуацию, ибо я уже начал думать, что где-то портятся данные jvm ;)
Резюме такое: с точки зрения стабильности приложения --- лучше упасть, а не продолжать работу, ибо что-то в коде не так. С точки зрения разработчика лучше не падать, а выдать системное сообщение с описанием проблемы. Поэтому, нужны какие-то настройки, можно даже в виде переменных окружения, которые бы позволили управлять поведением процесса. Возможно даже иметь трассировочную информацию по операциям с памятью. Это представляется критичным в случае разработки смешанных приложений Java+native, когда надо знать, что происходит внутри jvm, а что --- внутри нативного кода.