dlopen (3) может дать сбой и в этом случае дает NULL.И вы должны всегда проверять такой сбой (см. this ).Я предполагаю, что некоторые dlopen потерпели неудачу в вашем случае, но вы забыли проверить это (это может объяснить ваш this=0, о котором сообщали gdb в dlsym).Тем не менее, в Linux вы можете сделать сотни тысяч успешных dlopen -s, см. Мой пример manydl.c .Конечно, вы не должны использовать dlsym (3) с NULL дескриптором общего объекта (в противном случае это неопределенное поведение , с вероятной ошибкой сегментации ).
Чтобы найти, в частности, в Linux, по какому-либо адресу, к какой функции он может принадлежать, вы можете использовать dladdr (3) .
Обратите внимание, что core (5) Файлы знают о сегментах памяти mmap (если, возможно, они неполные, поскольку вы достигли некоторого предела, установленного с помощью setrlimit (2) с использованием RLIMIT_CORE)
Смотрите также proc (5) .Если вы можете воспроизвести вашу ошибку в каком-то процессе 1234, посмотрите на /proc/1234/maps, пока этот процесс все еще активен.
Где-то есть описание того, что скрывается за дескриптором dlopen ()?
Это некоторый абстрактный тип данных (используется только с dlopen, dlsym, dlclose и dlinfo (3) ... см. Также dl_iterate_phdr (3) .), Поэтому переносные программы не нуждаются в уходе.Конечно, вы можете изучить реализацию dlopen, например, внутри исходного кода GNU libc .См. Также /usr/include/link.h вашей системы и struct link_map (спасибо yugr комментарий)