多线程作为提升效率的一个手段，在当今越来越被广泛使用。然而由于并发引起的缺陷也越来越突出。数据竞争就是其中的一个主要缺陷类型。它是多个线程同时访问同一段内存，至少有一个是写访问。在由并发引起的缺陷中，数据竞争是最难暴露的缺陷之一，不仅是由于数据竞争触发时机比较苛刻，也由于引起的后果不确定。这两点导致数据竞争难以被动态分析方法捕获和重现。除此之外，数据竞争的修复也是一大困难，据统计[1]，71%的非死锁并发缺陷不是通过简单的加锁解决的，开发者需要考虑正确性、效率以及其他因素才决定一个修复策略。所以越早检测到数据竞争缺陷，相比于其他缺陷越能够降低开发成本。
https://github.com/transmission/transmission/issues/141
在下图中的报告中，我们发现在第128行创建了一个新的线程执行ThreadFunc函数，并将t作参数传递给ThreadFunc，随后在第129行使用了t的一个成员。
进入ThreadFunc我们发现，该函数在第106行调用了tr_free函数，而tr_free函数的主要用处是释放其参数所指向的内存。由此我们可以发现，如果该程序的线程调度顺序是ThreadFunc一直执行，而第129行的pthread_detach被推后到线程执行完tr_free函数，则会触发Use After free。
https://github.com/eribertomota/axel/issues/58
Axel是在Linux/Unix下的下载加速器。我们报告了其中关于search_sortlist的数据竞争。报告的路径一共有5个关键点，第一点和第四点在如下图的第237行和238行。在这个报告中，我们发现问题可能出在search_getspeeds和search_sortlist函数中，并且都是针对search这个参数。
search_getspeeds的部分细节见下图。201行创建了线程，在search_speedtest函数和search_sortlist函数中，有对search参数的数据竞争。
正常情况下，由于第193行的循环退出条件，除非所有线程都需要得到speed信息才会跳出循环。这样就可以保证search_sortlist函数无法与线程函数search_speedtest并发，从而不会发生数据竞争类错误。
但是问题出现在第209行，我们发现一旦线程创建失败就会直接调用return，此时在此之前创建的线程依旧执行，进而线程函数search_speedtest中的与其参数相关的变量都有可能与search_sortlist中的qsort函数中results数据竞争，导致最终结果出错。
[1] Lu, Shan, et al. "Learning from mistakes: a comprehensive study on real world concurrency bug characteristics." ACM Sigplan Notices. Vol. 43. No. 3. ACM, 2008.
