sleep(10); return 0;
}
cc+check=lock simple_race.c
./a.out
Runtime Error: locking discipline violation: in file simple_race.c line 16 address 40010658
(0)0x0000000004072ca0 _rtc_raise_fault + 0x2c0 at rtc_utils.c:382 [./a.out]
(1)0x0000000004028650 _ZN11DRD_Runtime15HandleMemAccessEybPcjS0_ + 0x590 at lock_check.C:438
[./a.out]
(2)0x0000000004029840
_ZN11DRD_Runtime17HandleStoreAccessEyPcjS0_ + 0x60 at lock_check.C:145
[./a.out]
(3)0x000000000401bfa0 __DRD_RegisterStoreAccess__ + 0x160 at lock_check.H:126 [./a.out]
(4)0x0000000004018780 thread2 + 0xd0 at simple_race.c:16 [./a.out]
(5)0x60000000c57c3c60 __pthread_bound_body + 0x170
at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:4512 [/proj/thlo/Compilers/rt/usr/lib/hpux32/libpthread.so.1]
candidate lockset is as follows: lock1.c line number:23 incoming lockset is as follows: lock1.c line number:13
In the above message, the candidate lockset refers to the set of locks that are implied to be associated with the symbol access in its previous accesses so far. The incoming lockset refers to the set of locks that are held at the current access of the symbol. When the intersection between the candidate lockset and incoming lockset is empty, the checker reports the locking discipline violation. The candidate lockset and incoming lockset members are specified in terms of the source file and line number pointing to the pthread_mutex_lock call associated with that lock. For further details on detecting lock discipline violations, refer to the
False positives are possible in certain cases, as mentioned in the Eraser article. Multiple locks can be used to protect the same shared variable. For example, a linked list can be protected by an overall lock and an individual entry lock. This can result in the tool reporting a false positive. False positives might also be reported as a result of memory getting recycled in certain cases because of deallocations (which the lock checker is not able to detect).
+check=stack[:frame:variables:none]
This option enables runtime checks to detect writes outside stack boundaries. Markers are placed before and after the whole stack frame and around some stack variables. On procedure exit, a check is done to see if any marker has been overwritten. If any stack check fails, an error message and stack trace is written to stderr and the program is aborted. The stack checks are not performed for an abnormal exit from the procedure (e.g. using longjmp(), exit(), abort() or exception handling).
+check=stack:frame
This option enables runtime checks for illegal writes from the current stack frame that overflow into the previous stack frame.
11