There are many references to "unknown signal 32" errors in Google.

Gdb mailing list, December 2002: "SIG32/SIGTRAP issues"
http://sources.redhat.com/ml/gdb/2002-12/msg00057.html

Gdb mailing list, September 2003: "pthread_create, Program received signal ?, Unknown signal"
http://sources.redhat.com/ml/gdb/2003-09/msg00003.html
=> extract: "A change in the definition of SIGRTMIN
causes this symptom."

There is a thread "SIGRT_0 (Unknown signal 32)" in the Linux Kernel mailing list, in July 2005:
http://lkml.org/lkml/2005/7/30/93

Extract of a Debian bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298982
-------------
There are actually three earlier instances in the trace of
 rt_sigsuspend([]  <unfinished ...>
in those cases it gets "SIGRTMIN (Unknown signal 32)" and carries on.
The one prior to the hanging instance is

 open("/dev/sequencer", O_WRONLY)        = 10
 ioctl(10, SNDCTL_SEQ_NRSYNTHS, 0x40095b20) = 0
 ioctl(10, SNDCTL_SEQ_NRMIDIS, 0x40094c20) = 0
 rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
 write(9, " \357\24@\0\0\0\0P\370\377\277\240\341\16@\220\376\23\10"..., 148) = 148
 rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
 rt_sigsuspend([] <unfinished ...>
 --- SIGRTMIN (Unknown signal 32) @ 0 (0) ---
 <... rt_sigsuspend resumed> )           = -1 EINTR (Interrupted system call)
 sigreturn()                             = ? (mask now [RTMIN])

(...)

This is not very helpful, as it means the thread is waiting for another
thread, nothing else. Could you run it with strace -f ?
-------------