Hi Kevin, On Wed, May 1, 2013 at 7:02 AM, Kevin Wills <[email protected]> wrote: > THREAD #1 > > (gdb) bt 20 > #0 0x0000003675c07ba5 in pthread_join () from /lib64/libpthread.so.0 > #1 0x0000000000406d92 in sortlines (lines=0x2af4898c1b50, nthreads=1, > total_lines=3913269, node=0x1dbf37b0, queue=0x7fffb16a4b80, tfp=0x1dbf32a0, > temp_output=0x1dbf323d > "/tmp/TEST.20100129.1367347586.5d6b2b011bb90cc1/sortrg8yHh") at > src/sort.c:3587 > #2 0x0000000000406d83 in sortlines (lines=0x2af48b69ccf0, nthreads=2, > total_lines=3913269, node=0x1dbf35b0, queue=0x7fffb16a4b80, tfp=0x1dbf32a0, > temp_output=0x1dbf323d > "/tmp/TEST.20100129.1367347586.5d6b2b011bb90cc1/sortrg8yHh") at > src/sort.c:3585 > #3 0x0000000000407191 in sort (files=0x6185b8, nfiles=0, output_file=0x0, > nthreads=4) at src/sort.c:3917 > #4 0x00000000004093a6 in main (argc=10, argv=0x7fffb16a5238) at > src/sort.c:4702 >
Took a quick look, noticed the above call stack is suspicious. The last call to sortlines before the pthread_join() is invoked with nthreads = 1, while in code sortlines would only call pthread_join() if nthreads > 1. I confirmed this in the disassembly as well to rule out the unlikely possibility this was the result of some compiler optimization (I used -O2). Did you compile this yourself or was it distributed with your system?
