HP C/aC++ for PA-RISC Software manual +check=malloc

void *thread2(void *arg) { pthread_mutex_lock(&mutex2); things_done++; pthread_mutex_unlock(&mutex2); return 0;

}

int main(int argc, char *argv[])

{

pthread_t th1, th2;

pthread_create(&th1, NULL, thread1, (void*)NULL ); pthread_mutex_lock(&mutex1);

things_done++;

pthread_mutex_unlock(&mutex1);

pthread_create(&th2, NULL, thread2, (void*)NULL ); sleep(10);

return 0;

}

cc+check=lock simple_race.c -lpthread

./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 acesss 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 above-referenced Eraser article.

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=malloc

The +check=malloc option enables memory leak and heap corruption checks at runtime. It will cause the user program to abort for writes beyond boundaries of heap objects, free or realloc calls for a pointer that is not a valid heap object, and out-of-memory conditions. Memory leak information is captured and written out to a log file when the program exits. The name of the logfile is printed out before program termination.

The +check=malloc option works by intercepting all heap allocation and deallocation calls. This is done by the use of a debug malloc library, librtc.so. The option works for programs that use the system malloc or for user provided malloc routines in a shared library. The librtc.so library is also used by the HP WDB debugger to provide heap memory checking features in the debugger. Please refer to the HP WDB debugger documentation for more information about heap memory checking. The librtc.so library is shipped as part of the wdb product.

Runtime Checking Options 79