Первый шаг — попробовать запустить функцию без создания потоков. Просто напишите файл .c с main, который делает минимум, чтобы подготовиться к запуску потока, а затем, вместо того, чтобы делать это, он просто вызывает функцию. Отлаживать намного проще, если вы можете воссоздать проблему только с одним потоком.

Кроме того, если вы используете gcc, вы должны скомпилировать с помощью:

-fstack-protector-all -Wstack-protector -fno-omit-frame-pointer

в дополнение к вашим обычным флагам (по крайней мере, пока вы не найдете проблему). Это поможет при отладке и, возможно, выдаст больше предупреждений во время компиляции. Я предполагаю, что вы знаете, как флаги -O могут повлиять на возможность отладки и функциональность (особенно если вы уже делаете что-то неправильное или не определенное в коде C).

Когда вы находитесь в GDB и все выглядит так, как будто они заблокированы или программе требуется много времени, чтобы что-то сделать, вы обычно можете нажать CTRL Z, чтобы вернуться к (gdb), не убивая программу. Это выдает сигнал остановки программе и позволяет вам снова взаимодействовать с GDB, чтобы вы могли узнать, что на самом деле делает программа.

редактировать

Очевидно, я решил проблему в обсуждении в комментариях, поэтому напишу здесь, в чем была проблема.

Беглый взгляд на код не выявил проблемы, которая привела бы к ошибке сегментации (незаконному доступу к памяти), и Zypsy (ОП) сказал мне, что функция работает нормально при вызове непосредственно из основного, а не через отдельный нить.

Valgrind сообщил, что пространство стека потока не удалось расширить до определенного адреса. В Linux стек основного потока сопоставляется с приложением таким образом, что его можно легко увеличивать, но это часто не делается, когда память выделяется для стеков потоков.

Я попросил Zypsy (ОП) вставить некоторый код, который распечатывал бы адрес чего-то, что известно как низкое в стеке потоков (printf("thread stk = %p\n", &input);), чтобы это значение можно было сравнить с адресом, указанным в сообщении об ошибке. Из этого я мог получить предположение о размере стека. Это не говорит о том, что между началом функции потока и ее сбоем было израсходовано очень много места в стеке, но пространство также не казалось слишком маленьким для кода в вопросе (хотя, видимо, оно оказалось слишком маленьким).

Поскольку функция pthread_create позволяет вам либо принять настройки для атрибутов потока (передать NULL), либо передать аргумент, определяющий различные настройки для потока, я спросил, можно ли опубликовать код, вызывающий pthread_create, чтобы я мог видеть, есть ли были какие-либо подозрительные настройки.

Посмотрев на этот код (конкретная оболочка приложения для различных функций pthread_), я увидел, что на самом деле были установлены некоторые атрибуты, связанные со стеком. Я попросил OP просмотреть вызовы этой функции и найти подозрительные вещи, связанные с тем, как был выделен стек (убедитесь, что значение размера и размер выделенной памяти на самом деле совпадают). Оказалось, что затем ОП обнаружил, что стек этого потока выделяется меньше, чем стеки других потоков. В конце концов, стек был слишком мал.

Обычно такие проблемы связаны с повреждением памяти. Прекрасным примером являются такие симптомы, как несогласованные ошибки сегментации в разных строках при незначительном изменении кода.

Попробуйте запустить свою программу с помощью такого инструмента, как valgrind, вы гарантированно увидите некоторые незаконные обращения к памяти. Исправьте их, и я подозреваю, что все будет работать.