On Mon, Sep 10, 2007 at 01:41:23AM -0400, Jeff King wrote: > this series, --threads=8 > > I get a segfault very early in the deltification process, but I haven't > been able to track it very far. gdb reports it at varying locations in > the code, and I don't have valgrind or electric fence available at the > moment to get a more accurate idea of the cause. I might be able to look > at it more later. OK, I did manage to run valgrind on it. It reports: ==18693== Conditional jump or move depends on uninitialised value(s) ==18693== at 0x4348F9: threaded_find_deltas (builtin-pack-objects.c:1601) ==18693== by 0x4C3AF19: start_thread (in /lib/libpthread-2.3.6.so) ==18693== by 0x4E136C1: clone (in /lib/libc-2.3.6.so) So the 'list_size' variable for one of the threads isn't getting initialized. And indeed, if I instrument the pthread_mutex_lock calls, I see that one of the threads acquires the "data_ready" lock without the main thread providing any data. I think I am seeing something like this: - thread A gets data_request lock - thread A unlocks data_provider lock, signaling provider - thread A blocks getting data_ready lock - provider allocates work for A, unlocking data_ready to signal A - provider unlocks data_request lock, ready for next request - thread B gets data_request lock - thread B unlocks data_provider lock, signaling provider - thread B gets data_ready lock, because A still hasn't run yet - thread B tries to run on bogus data, since provider hasn't actually allocated any work yet So your locking scheme doesn't work, because signaling a thread with "ready" doesn't necessarily mean you're getting the same thread that you just gave data to. I think you could do it with another signal from the requesting thread to the provider that says "I got the work you assigned". The provider would wait on that mutex before allowing the next request. However, I wonder if there might be a simpler scheme...surely the "provide chunks of work to worker threads" is a common multithreading pattern and there is some canonical implementation. -Peff - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
