staticanalysis / data-race-test

Automatically exported from code.google.com/p/data-race-test
0 stars 0 forks source link

TSanThread::HandleBarrierInit(uintptr_t, uint32_t)): Assertion 'n > 0' failed #106

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Hi, I am trying to run the valgrind-tsan binary inside a Ubuntu 12.04 LTS 64bit 
VM but get some problems whereby I am not sure if the failed assertion plays a 
role.

==14812== ThreadSanitizer, a data race detector
==14812== Copyright (C) 2008-2010, and GNU GPL'd, by Google Inc.
==14812== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info
==14812== Command: debug_build/dist/bin/firefox
==14812== 
==14812== ThreadSanitizerValgrind r4397: hybrid=no
==14812== INFO: Reading ignore file: tsan.ignore
==14812== INFO: Allocating 256Mb (32 * 8M) for Segments.
==14812== INFO: Will allocate up to 640Mb for 'previous' stack traces.
==14813== ThreadSanitizer, a data race detector
==14813== Copyright (C) 2008-2010, and GNU GPL'd, by Google Inc.
==14813== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info
==14813== Command: debug_build/dist/bin/firefox
==14813== Parent PID: 14812
==14813== 

ThreadSanitizer: thread_sanitizer.cc:4929 (void 
TSanThread::HandleBarrierInit(uintptr_t, uint32_t)): Assertion 'n > 0' failed.
==14813==    at 0x3807D667: report_and_quit (m_libcassert.c:210)
==14813==    by 0x3807D8A0: vgPlain_assert_fail (m_libcassert.c:284)
==14813==    by 0x3802F524: ThreadSanitizerHandleOneEvent(Event*) 
(thread_sanitizer.cc:4929)
==14813==    by 0x38067BF1: Put(EventType, int, unsigned long, unsigned long, 
unsigned long) (ts_valgrind.cc:442)
==14813==    by 0x38068953: ts_handle_client_request(unsigned int, unsigned 
long*, unsigned long*) (ts_valgrind.cc:768)
==14813==    by 0x380C00F4: do_client_request (scheduler.c:1790)
==14813==    by 0x380C1D28: vgPlain_scheduler (scheduler.c:1184)
==14813==    by 0x380EB4C9: run_a_thread_NORETURN (syswrap-linux.c:98)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==14813==    at 0x4C30610: pthread_barrier_init (ts_valgrind_intercepts.c:1436)
==14813==    by 0x11BD739E: lp_rast_create (in 
/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so)
==14813==    by 0x11BBF2E6: llvmpipe_create_screen (in 
/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so)
==14813==    by 0x11B95A17: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so)
==14813==    by 0x11B9900F: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so)
==14813==    by 0x11B965F7: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so)
==14813==    by 0x10EFACC5: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2)
==14813==    by 0x10EDA3B7: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2)
==14813==    by 0x10ED6A17: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2)
==14813==    by 0x10ED6D0C: glXChooseVisual (in 
/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2)
==14813==    by 0x79D4751: glxtest() (glxtest.cpp:159)
==14813==    by 0x79D4A3D: fire_glxtest_process() (glxtest.cpp:234)
==14813==    by 0x79C9A36: XREMain::XRE_mainInit(nsXREAppData const*, bool*) 
(nsAppRunner.cpp:2820)
==14813==    by 0x79CECA9: XREMain::XRE_main(int, char**, nsXREAppData const*) 
(nsAppRunner.cpp:3838)
==14813==    by 0x79CEFE1: XRE_main (nsAppRunner.cpp:3933)
==14813==    by 0x401E2A: main (nsBrowserApp.cpp:174)

Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: data-race-test@googlegroups.com

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

==14812== 
==14812== ThreadSanitizer summary: reported 0 warning(s) (0 race(s))
tsan-valgrind/linux_x64/bin/valgrind-tsan.sh: line 24: 14812 Killed             
     $EXTRACT_DIR/bin/valgrind --tool=tsan "$@"

Original issue reported on code.google.com by cdieh...@gmail.com on 15 Oct 2012 at 2:40

GoogleCodeExporter commented 9 years ago
Hi,

It looks like a bug both in OpenGL -- it creates a barrier with 0 threads:

   /* for synchronizing rasterization threads */
   pipe_barrier_init( &rast->barrier, rast->num_threads );

while man says "The value specified by count must be greater than zero".

and in ThreadSanitizer -- it must return EINVAL.

Currently we are working on the next generation ThreadSanitzer v2:
http://clang.llvm.org/docs/ThreadSanitizer.html
I would suggest trying it first.

Original comment by dvyu...@google.com on 17 Oct 2012 at 8:36