I also don't see that main() is waiting for the receiving thread to finish... It should. You can't create a thread and quit the same way you can fork a process and quit because when main's thread quits, the entire process is gone.
Any idea where the segfault happens? compile with -ggdb, and run with 'gdb ./filename', start it with 'run' inside gdb, then 'bt f' after it crashes to see a backtrace.
I didn't performed a deep analysis of your code, but I might shed some lights on the problem you're facing.
Yes, generally speaking your are correct. But notice here that main() calls pthread_exit(). In this case, the program will happily continue to perform until the thread Recv_Handle ceases to exit (assuming that the process only have these two threads). Detailed explanations about the main thread semantic can be found here: The main thread.
However I see a fundamental flaw: the way the receivedSocket is passed to the Recv_Handle thread. In the original posted code, you have a race condition. Indeed receivedSocket is a local variable stored on the main's stack. However, when the main() executes the pthread_exit(), receivedSocket becomes then undefined (indeed, the stack is usually located on a memory that is freed upon pthread_exit). When Recv_Handle thread accesses this variable, possibly main has already executed pthread_exit(). This can happen, because of the asynchronous nature of pthread_create(). At this point, all bets are off and you get a SIGSEGV.
The following article explains you how to pass (correctly) arguments between threads: Pthreads arguments passing.
This is may provide a help, but nevertheless the program remains incorrect because of the way the argument is passed, as explained here: Joinable and Detached Threads.
Besides that, in the original code, you are closing the recvSocket... recvfrom() in Recv_Handle thread should fail. If I find some times tomorrow, I'll review your code thoroughly.