there are several data races related to e.g. svc_to_mds_info structure, one example below:
Possible data race during write of size 4 at 0x35F72C by thread #4
==769== Locks held: none
==769== at 0x129E05: memset (string3.h:84)
==769== by 0x129E05: mds_service_retrieve (mdstipc_conf.c:1619)
==769== by 0x1120C4: tet_vdest_rcvr_thread (mdstipc_api.c:5584)
==769== by 0x4C30FA6: ??? (in /hostfs/rootfs/usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==769== by 0x50CC183: start_thread (pthread_create.c:312)
==769== by 0x53DFFFC: clone (clone.S:111)
==769==
==769== This conflicts with a previous write of size 4 by thread #1
==769== Locks held: none
==769== at 0x12A0F3: memset (string3.h:84)
==769== by 0x12A0F3: mds_service_uninstall (mdstipc_conf.c:435)
==769== by 0x116547: tet_cleanup_setup (mdstipc_api.c:2726)
==769== by 0x11BCBF: tet_send_response_ack_tp_5 (mdstipc_api.c:6726)
==769== by 0x12B928: run_test_case (utest.c:178)
==769== by 0x12BD6D: test_run (utest.c:226)
==769== by 0x10DBA8: main (mdstest.c:92)
==769== Address 0x35f72c is 12 bytes inside data symbol "svc_to_mds_info"
==769==
==769==
this is likely the cause why some mds tests sometimes fails "randomly". The mds tests has to be thread safe and helgrind can be used to identify these thread synchronization issues.
https://sourceforge.net/p/opensaf/mailman/message/36269820/
Release branch:
commit d158f2aa831a55673214c4e7640d1fcaaf7ce7b3
Author: Hoa Le hoa.le@dektech.com.au
Date: Thu Mar 22 19:31:39 2018 +0700
commit 24f02c09aaf15b264b9e37fd945329db4f00701a
Author: Hoa Le hoa.le@dektech.com.au
Date: Tue Mar 27 14:11:35 2018 +0700
Develop branch:
commit dac6b5bf582e581252f21d32b470f91d5629b867
Author: Hoa Le hoa.le@dektech.com.au
Date: Thu Mar 22 19:31:39 2018 +0700
commit 2e1b1228d0bb8f7aa66773f11ff915d5a39b0748
Author: Hoa Le hoa.le@dektech.com.au
Date: Tue Mar 27 14:11:35 2018 +0700
Related
Tickets:
#2746Last edit: Hoa Le 2018-03-27