Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compilation error on MAC OSX #2

Closed
sunlinh opened this issue Jul 15, 2016 · 4 comments
Closed

Compilation error on MAC OSX #2

sunlinh opened this issue Jul 15, 2016 · 4 comments
Assignees

Comments

@sunlinh
Copy link

sunlinh commented Jul 15, 2016

I encountered errors when compiling libnetconf2 on my MAC, it seems that the MAC OSX does not support pthread_rwlock_t and CLOCK_REALTIME. The error log is :

sunlinhuideAir:build sunlinhui$ make
Scanning dependencies of target netconf2
[ 4%] Building C object CMakeFiles/netconf2.dir/src/io.c.o
In file included from /Users/sunlinhui/Documents/workspace/libnetconf2/src/io.c:29:
In file included from /Users/sunlinhui/Documents/workspace/libnetconf2/src/libnetconf.h:22:
/Users/sunlinhui/Documents/workspace/libnetconf2/src/session_p.h:195:5: error:
unknown type name 'pthread_spinlock_t'; did you mean 'pthread_rwlock_t'?
pthread_spinlock_t sid_lock;
^~~~~~~~~~~~~~~~~~
pthread_rwlock_t
/usr/include/sys/_pthread/_pthread_rwlock_t.h:30:35: note: 'pthread_rwlock_t'
declared here
typedef __darwin_pthread_rwlock_t pthread_rwlock_t;
^
/Users/sunlinhui/Documents/workspace/libnetconf2/src/io.c:459:19: warning:
implicit declaration of function 'ppoll' is invalid in C99
[-Wimplicit-function-declaration]
ret = ppoll(&fds, 1, (timeout == -1 ? NULL : &ts_timeout), &...
^
1 warning and 1 error generated.
make[2]: *** [CMakeFiles/netconf2.dir/src/io.c.o] Error 1
make[1]: *** [CMakeFiles/netconf2.dir/all] Error 2
make: *** [all] Error 2

Any idea?

@rkrejci rkrejci self-assigned this Jul 15, 2016
@rkrejci
Copy link
Collaborator

rkrejci commented Jul 15, 2016

Please try to compile macosx branch if it works now. I'm going to try to use building on OS X in Travis CI, but it is not working yet.

@sunlinh
Copy link
Author

sunlinh commented Jul 15, 2016

Hi Radek,

Thanks for doing that, I tried the new branch and pthread_rwlock_t issue is resolved but the CLOCK_REALTIME I mentioned is still not resolved in macosx branch, the error log is:
sunlinhuideAir:build sunlinhui$ make
Scanning dependencies of target netconf2
[ 4%] Building C object CMakeFiles/netconf2.dir/src/io.c.o
[ 8%] Building C object CMakeFiles/netconf2.dir/src/log.c.o
[ 12%] Building C object CMakeFiles/netconf2.dir/src/messages_client.c.o
[ 16%] Building C object CMakeFiles/netconf2.dir/src/messages_server.c.o
[ 20%] Building C object CMakeFiles/netconf2.dir/src/session.c.o
/Users/sunlinhui/Documents/workspace/libnetconf2-macosx/src/session.c:60:9: warning:
implicit declaration of function 'clock_gettime' is invalid in C99
[-Wimplicit-function-declaration]
clock_gettime(CLOCK_REALTIME, &ts_timeout);
^
/Users/sunlinhui/Documents/workspace/libnetconf2-macosx/src/session.c:60:23: error:
use of undeclared identifier 'CLOCK_REALTIME'
clock_gettime(CLOCK_REALTIME, &ts_timeout);
^
/Users/sunlinhui/Documents/workspace/libnetconf2-macosx/src/session.c:65:15: warning:
implicit declaration of function 'pthread_mutex_timedlock' is invalid in
C99 [-Wimplicit-function-declaration]
ret = pthread_mutex_timedlock(lock, &ts_timeout);

@rkrejci
Copy link
Collaborator

rkrejci commented Jul 15, 2016

I was able to set up automatic OS X builds in Travis CI and I'm continuing with fixing other compat issues.

@rkrejci rkrejci reopened this Jul 15, 2016
@rkrejci
Copy link
Collaborator

rkrejci commented Jul 15, 2016

The code should works in the current master branch. In Travis we have still some issues with opnessl, but if you are able to correctly use libssl and llibcrypto in OS X, it should works for you.

@rkrejci rkrejci closed this as completed Jul 15, 2016
jktjkt added a commit to jktjkt/libnetconf2 that referenced this issue Nov 21, 2016
On my version of OpenSSL (openssl-1.0.2j on Gentoo Linux), the original
version of this code resulted in a small memleak reoprted by ASAN:

  Direct leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0x4d5460 in malloc /var/tmp/portage/sys-devel/llvm-3.9.0/work/llvm-3.9.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
    CESNET#1 0x7f8fff9cb7fc in CRYPTO_malloc /var/tmp/portage/dev-libs/openssl-1.0.2j/work/openssl-1.0.2j-abi_x86_64.amd64/crypto/mem.c:346
    CESNET#2 0x7f8fffcd372b in load_builtin_compressions /var/tmp/portage/dev-libs/openssl-1.0.2j/work/openssl-1.0.2j-abi_x86_64.amd64/ssl/ssl_ciph.c:487
    CESNET#3 0x7f8fffcd5b5a in SSL_COMP_get_compression_methods /var/tmp/portage/dev-libs/openssl-1.0.2j/work/openssl-1.0.2j-abi_x86_64.amd64/ssl/ssl_ciph.c:1962
    CESNET#4 0x7f8fffcdc6b1 in SSL_library_init /var/tmp/portage/dev-libs/openssl-1.0.2j/work/openssl-1.0.2j-abi_x86_64.amd64/ssl/ssl_algs.c:150
    CESNET#5 0x7f90005ea466 in nc_ssh_tls_init /home/jkt/work/prog/libnetconf2/build/../src/session.c:1165:5
    CESNET#6 0x7f90005ea448 in nc_init /home/jkt/work/prog/libnetconf2/build/../src/session.c:1209:5
    CESNET#7 0x7f90005fe7c5 in nc_server_init /home/jkt/work/prog/libnetconf2/build/../src/session_server.c:430:5
    CESNET#8 0x50ffd8 in main /home/jkt/work/prog/libnetconf2/build/../tests/test_fd_comm.c:335:5
    CESNET#9 0x7f8ffe93e733 in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    CESNET#10 0x419e18 in _start (/home/jkt/work/prog/libnetconf2/build/tests/test_fd_comm+0x419e18)

Upstream OpenSSL's issue tracker suggests [1] to use
SSL_COMP_add_compression_method [2]. That particular overload was only
added in 1.0.2, and since 1.1.0, it's deprecated and documented [3] to
be a no-op. RHEL6 comes with 1.0.1.

TL;DR: it's an API-compatibility mess, but it fixes a leak. It shouldn't
break the build.

[1] https://rt.openssl.org/Ticket/Display.html?id=2561&user=guest&pass=guest
[2] https://www.openssl.org/docs/man1.0.2/ssl/SSL_COMP_add_compression_method.html
[3] https://www.openssl.org/docs/man1.1.0/ssl/SSL_COMP_add_compression_method.html
jktjkt added a commit to jktjkt/libnetconf2 that referenced this issue Nov 21, 2016
On my version of OpenSSL (openssl-1.0.2j on Gentoo Linux), the original
version of this code resulted in a small memleak reoprted by ASAN:

  Direct leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0x4d5460 in malloc /var/tmp/portage/sys-devel/llvm-3.9.0/work/llvm-3.9.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
    CESNET#1 0x7f8fff9cb7fc in CRYPTO_malloc /var/tmp/portage/dev-libs/openssl-1.0.2j/work/openssl-1.0.2j-abi_x86_64.amd64/crypto/mem.c:346
    CESNET#2 0x7f8fffcd372b in load_builtin_compressions /var/tmp/portage/dev-libs/openssl-1.0.2j/work/openssl-1.0.2j-abi_x86_64.amd64/ssl/ssl_ciph.c:487
    CESNET#3 0x7f8fffcd5b5a in SSL_COMP_get_compression_methods /var/tmp/portage/dev-libs/openssl-1.0.2j/work/openssl-1.0.2j-abi_x86_64.amd64/ssl/ssl_ciph.c:1962
    CESNET#4 0x7f8fffcdc6b1 in SSL_library_init /var/tmp/portage/dev-libs/openssl-1.0.2j/work/openssl-1.0.2j-abi_x86_64.amd64/ssl/ssl_algs.c:150
    CESNET#5 0x7f90005ea466 in nc_ssh_tls_init /home/jkt/work/prog/libnetconf2/build/../src/session.c:1165:5
    CESNET#6 0x7f90005ea448 in nc_init /home/jkt/work/prog/libnetconf2/build/../src/session.c:1209:5
    CESNET#7 0x7f90005fe7c5 in nc_server_init /home/jkt/work/prog/libnetconf2/build/../src/session_server.c:430:5
    CESNET#8 0x50ffd8 in main /home/jkt/work/prog/libnetconf2/build/../tests/test_fd_comm.c:335:5
    CESNET#9 0x7f8ffe93e733 in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    CESNET#10 0x419e18 in _start (/home/jkt/work/prog/libnetconf2/build/tests/test_fd_comm+0x419e18)

Upstream OpenSSL's issue tracker suggests [1] to use
SSL_COMP_add_compression_method [2]. That particular overload was only
added in 1.0.2, and since 1.1.0, it's deprecated and documented [3] to
be a no-op. RHEL6 comes with 1.0.1.

TL;DR: it's an API-compatibility mess, but it fixes a leak. It shouldn't
break the build.

[1] https://rt.openssl.org/Ticket/Display.html?id=2561&user=guest&pass=guest
[2] https://www.openssl.org/docs/man1.0.2/ssl/SSL_COMP_add_compression_method.html
[3] https://www.openssl.org/docs/man1.1.0/ssl/SSL_COMP_add_compression_method.html
rjarry added a commit to 6WIND/libnetconf2 that referenced this issue Oct 10, 2018
This fixes a segfault when running nc_connect_ssh_channel().

 #0  __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:65
 CESNET#1  0x00007f0b38c0edf8 in nc_session_io_lock (session=0x561dc93a73b0, timeout=-1,
     func=0x7f0b38c36d60 <__func__.24731> "nc_connect_ssh_channel")
     at libnetconf2/src/session.c:347
 CESNET#2  0x00007f0b38c25f23 in nc_connect_ssh_channel (session=0x561dc8cc3200, ctx=0x561dc8cc7130)
     at libnetconf2/src/session_client_ssh.c:1753

Fixes: 131120a ("CHANGE allow concurrent notifications and RPCs")
Signed-off-by: Robin Jarry <robin.jarry@6wind.com>
jktjkt added a commit to jktjkt/libnetconf2 that referenced this issue Oct 8, 2021
In the Netopeer2 test suite, two threads were calling getpwuid(), which
is not a reentrant function. Here's a trace from TSAN:

WARNING: ThreadSanitizer: data race (pid=3803971)
  Write of size 8 at 0x7fc95e073f40 by thread T2:
    #0 getpwuid <null> (test_parallel_sessions+0x4367d4)
    CESNET#1 nc_connect_unix libnetconf2/src/session_client.c:1270:10 (libnetconf2.so.2+0x1ba34)
    CESNET#2 send_get_rpc Netopeer2/tests/test_parallel_sessions.c:68:15 (test_parallel_sessions+0x4ea807)

  Previous write of size 8 at 0x7fc95e073f40 by thread T1:
    #0 getpwuid <null> (test_parallel_sessions+0x4367d4)
    CESNET#1 nc_connect_unix libnetconf2/src/session_client.c:1270:10 (libnetconf2.so.2+0x1ba34)
    CESNET#2 send_get_rpc Netopeer2/tests/test_parallel_sessions.c:68:15 (test_parallel_sessions+0x4ea807)

  Location is global 'resbuf.11357' of size 48 at 0x7fc95e073f40 (libc.so.6+0x1bcf40)

  Thread T2 (tid=3807449, running) created by main thread at:
    #0 pthread_create <null> (test_parallel_sessions+0x469032)
    CESNET#1 test_first Netopeer2/tests/test_parallel_sessions.c:115:9 (test_parallel_sessions+0x4ea6c2)
    CESNET#2 cmocka_run_one_test_or_fixture <null> (libcmocka.so.0+0x630e)

  Thread T1 (tid=3807448, running) created by main thread at:
    #0 pthread_create <null> (test_parallel_sessions+0x469032)
    CESNET#1 test_first Netopeer2/tests/test_parallel_sessions.c:115:9 (test_parallel_sessions+0x4ea6ad)
    CESNET#2 cmocka_run_one_test_or_fixture <null> (libcmocka.so.0+0x630e)

SUMMARY: ThreadSanitizer: data race (Netopeer2/tests/test_parallel_sessions+0x4367d4) in __interceptor_getpwuid

Fix that by switching to getpwuid_r(). The code is very similar to the
auth_password_getpwnam() wrapper from session_server_ssh.c. I chose to
put this into io.c even though it is not really an IO function, but the
existing nc_realloc() is in that file as well.
michalvasko pushed a commit that referenced this issue Oct 11, 2021
In the Netopeer2 test suite, two threads were calling getpwuid(), which
is not a reentrant function. Here's a trace from TSAN:

WARNING: ThreadSanitizer: data race (pid=3803971)
  Write of size 8 at 0x7fc95e073f40 by thread T2:
    #0 getpwuid <null> (test_parallel_sessions+0x4367d4)
    #1 nc_connect_unix libnetconf2/src/session_client.c:1270:10 (libnetconf2.so.2+0x1ba34)
    #2 send_get_rpc Netopeer2/tests/test_parallel_sessions.c:68:15 (test_parallel_sessions+0x4ea807)

  Previous write of size 8 at 0x7fc95e073f40 by thread T1:
    #0 getpwuid <null> (test_parallel_sessions+0x4367d4)
    #1 nc_connect_unix libnetconf2/src/session_client.c:1270:10 (libnetconf2.so.2+0x1ba34)
    #2 send_get_rpc Netopeer2/tests/test_parallel_sessions.c:68:15 (test_parallel_sessions+0x4ea807)

  Location is global 'resbuf.11357' of size 48 at 0x7fc95e073f40 (libc.so.6+0x1bcf40)

  Thread T2 (tid=3807449, running) created by main thread at:
    #0 pthread_create <null> (test_parallel_sessions+0x469032)
    #1 test_first Netopeer2/tests/test_parallel_sessions.c:115:9 (test_parallel_sessions+0x4ea6c2)
    #2 cmocka_run_one_test_or_fixture <null> (libcmocka.so.0+0x630e)

  Thread T1 (tid=3807448, running) created by main thread at:
    #0 pthread_create <null> (test_parallel_sessions+0x469032)
    #1 test_first Netopeer2/tests/test_parallel_sessions.c:115:9 (test_parallel_sessions+0x4ea6ad)
    #2 cmocka_run_one_test_or_fixture <null> (libcmocka.so.0+0x630e)

SUMMARY: ThreadSanitizer: data race (Netopeer2/tests/test_parallel_sessions+0x4367d4) in __interceptor_getpwuid

Fix that by switching to getpwuid_r(). The code is very similar to the
auth_password_getpwnam() wrapper from session_server_ssh.c. I chose to
put this into io.c even though it is not really an IO function, but the
existing nc_realloc() is in that file as well.
jktjkt added a commit to jktjkt/libnetconf2 that referenced this issue Mar 30, 2022
Our internal test suite fed mismatched replies to libnetconf2. The
library was trying to request the ietf-yang-library data, and because of
some preceding replies which sent garbage instead of that module's
YANG source, the library was apparently not able to send a proper
request. Instead, the following command was sent:

 libyang[0]: Unexpected module "ietf-yang-metadata" parsed instead of "ietf-origin").
 libyang[0]: Parsing module "ietf-yang-metadata" failed.
 libyang[0]: Loading "ietf-origin" module failed.
 libyang[0]: Parsing module "ietf-netconf-nmda" failed.
 Session 1 [INF]: Support for <get-data> from ietf-netconf-nmda not found.
 libyang[0]: Failed to resolve prefix "ietf-yang-library".
 Session 1 [DBG]: Sending message:

 CESNET#165

 Session 1 [DBG]: Sending message:
 <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4"><get xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><filter type="xpath" select=""/></get></rpc>

That in istelf is an error (libnetconf2 should have died much sooner
when the server responds with garbage), but that's not what I am fixing
here. Our broken test suite responded with:

 <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4"><data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">   module ietf-yang-library {
     yang-version 1.1;
     namespace &quot;urn:ietf:params:xml:ns:yang:ietf-yang-library&quot;;
     prefix yanglib;
 ...

This ended up as a segfault:

 libnetconf2/src/session_client.c:828:71: runtime error: member access within null pointer of type 'const struct lysc_node'

 #0 0x7f4ac54350ae in build_schema_info_yl libnetconf2/src/session_client.c:828:71
 CESNET#1 0x7f4ac54350ae in nc_ctx_check_and_fill libnetconf2/src/session_client.c:1218:13
 CESNET#2 0x7f4ac54394d9 in nc_connect_inout libnetconf2/src/session_client.c:1289:9
 CESNET#3 0x7f4ac5b55201 in libnetconf::client::Session::connectFd(int, int, std::optional<libyang::Context>) libnetconf2-cpp/src/netconf-client.cpp:244:46

The fix prevents the segfault, and libnetconf2 now "fails cleanly" even
with out broken test suite.

Another problem (libnetconf2 doesn't disconnect quickly enough when the
YANG schemas requested from libyang do not match those which were
actually requested) remains unfixed.
michalvasko pushed a commit that referenced this issue Mar 31, 2022
Our internal test suite fed mismatched replies to libnetconf2. The
library was trying to request the ietf-yang-library data, and because of
some preceding replies which sent garbage instead of that module's
YANG source, the library was apparently not able to send a proper
request. Instead, the following command was sent:

 libyang[0]: Unexpected module "ietf-yang-metadata" parsed instead of "ietf-origin").
 libyang[0]: Parsing module "ietf-yang-metadata" failed.
 libyang[0]: Loading "ietf-origin" module failed.
 libyang[0]: Parsing module "ietf-netconf-nmda" failed.
 Session 1 [INF]: Support for <get-data> from ietf-netconf-nmda not found.
 libyang[0]: Failed to resolve prefix "ietf-yang-library".
 Session 1 [DBG]: Sending message:

 #165

 Session 1 [DBG]: Sending message:
 <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4"><get xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><filter type="xpath" select=""/></get></rpc>

That in istelf is an error (libnetconf2 should have died much sooner
when the server responds with garbage), but that's not what I am fixing
here. Our broken test suite responded with:

 <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4"><data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">   module ietf-yang-library {
     yang-version 1.1;
     namespace &quot;urn:ietf:params:xml:ns:yang:ietf-yang-library&quot;;
     prefix yanglib;
 ...

This ended up as a segfault:

 libnetconf2/src/session_client.c:828:71: runtime error: member access within null pointer of type 'const struct lysc_node'

 #0 0x7f4ac54350ae in build_schema_info_yl libnetconf2/src/session_client.c:828:71
 #1 0x7f4ac54350ae in nc_ctx_check_and_fill libnetconf2/src/session_client.c:1218:13
 #2 0x7f4ac54394d9 in nc_connect_inout libnetconf2/src/session_client.c:1289:9
 #3 0x7f4ac5b55201 in libnetconf::client::Session::connectFd(int, int, std::optional<libyang::Context>) libnetconf2-cpp/src/netconf-client.cpp:244:46

The fix prevents the segfault, and libnetconf2 now "fails cleanly" even
with out broken test suite.

Another problem (libnetconf2 doesn't disconnect quickly enough when the
YANG schemas requested from libyang do not match those which were
actually requested) remains unfixed.
jktjkt added a commit to jktjkt/libnetconf2 that referenced this issue Apr 10, 2024
In the `test_ch` test, the `test_nc_ch_tls` case would result in the
following report:

 WARNING: ThreadSanitizer: data race (pid=7309)
   Write of size 8 at 0x7b24000148e0 by thread T6:
     #0 pthread_cond_destroy <null> (test_ch+0x459fd1) (BuildId: 0dd508005b002d2a874ae63746b8b5ea13e50df5)
     CESNET#1 nc_ch_client_thread /home/ci/src/cesnet-gerrit-public/CzechLight/dependencies/libnetconf2/src/session_server.c:2909:5 (test_ch+0x4f9f85) (BuildId: 0dd508005b002d2a874ae63746b8b5ea13e50df5)

   Previous read of size 8 at 0x7b24000148e0 by thread T5 (mutexes: write M0, write M1):
     #0 pthread_cond_signal <null> (test_ch+0x459c6c) (BuildId: 0dd508005b002d2a874ae63746b8b5ea13e50df5)
     CESNET#1 nc_server_config_destroy_ch_client /home/ci/src/cesnet-gerrit-public/CzechLight/dependencies/libnetconf2/src/server_config.c:920:9 (test_ch+0x4fb12a) (BuildId: 0dd508005b002d2a874ae63746b8b5ea13e50df5)
     CESNET#2 nc_server_config_ch /home/ci/src/cesnet-gerrit-public/CzechLight/dependencies/libnetconf2/src/server_config.c:1039:9 (test_ch+0x4fdd27) (BuildId: 0dd508005b002d2a874ae63746b8b5ea13e50df5)
     CESNET#3 nc_server_config_setup_data /home/ci/src/cesnet-gerrit-public/CzechLight/dependencies/libnetconf2/src/server_config.c:4211:5 (test_ch+0x4fdd27)
     CESNET#4 server_thread_tls /home/ci/src/cesnet-gerrit-public/CzechLight/dependencies/libnetconf2/tests/test_ch.c:307:11 (test_ch+0x522849) (BuildId: 0dd508005b002d2a874ae63746b8b5ea13e50df5)

The pthread_cond_destroy(3p) documentation says that:

> It shall be safe to destroy an initialized condition variable upon
> which no threads are currently blocked. Attempting to destroy a
> condition variable upon which other threads are
> currently blocked results in undefined behavior.

Let's make sure that this is the case by locking the associated mutex.
michalvasko pushed a commit that referenced this issue Apr 10, 2024
In the `test_ch` test, the `test_nc_ch_tls` case would result in the
following report:

 WARNING: ThreadSanitizer: data race (pid=7309)
   Write of size 8 at 0x7b24000148e0 by thread T6:
     #0 pthread_cond_destroy <null> (test_ch+0x459fd1) (BuildId: 0dd508005b002d2a874ae63746b8b5ea13e50df5)
     #1 nc_ch_client_thread /home/ci/src/cesnet-gerrit-public/CzechLight/dependencies/libnetconf2/src/session_server.c:2909:5 (test_ch+0x4f9f85) (BuildId: 0dd508005b002d2a874ae63746b8b5ea13e50df5)

   Previous read of size 8 at 0x7b24000148e0 by thread T5 (mutexes: write M0, write M1):
     #0 pthread_cond_signal <null> (test_ch+0x459c6c) (BuildId: 0dd508005b002d2a874ae63746b8b5ea13e50df5)
     #1 nc_server_config_destroy_ch_client /home/ci/src/cesnet-gerrit-public/CzechLight/dependencies/libnetconf2/src/server_config.c:920:9 (test_ch+0x4fb12a) (BuildId: 0dd508005b002d2a874ae63746b8b5ea13e50df5)
     #2 nc_server_config_ch /home/ci/src/cesnet-gerrit-public/CzechLight/dependencies/libnetconf2/src/server_config.c:1039:9 (test_ch+0x4fdd27) (BuildId: 0dd508005b002d2a874ae63746b8b5ea13e50df5)
     #3 nc_server_config_setup_data /home/ci/src/cesnet-gerrit-public/CzechLight/dependencies/libnetconf2/src/server_config.c:4211:5 (test_ch+0x4fdd27)
     #4 server_thread_tls /home/ci/src/cesnet-gerrit-public/CzechLight/dependencies/libnetconf2/tests/test_ch.c:307:11 (test_ch+0x522849) (BuildId: 0dd508005b002d2a874ae63746b8b5ea13e50df5)

The pthread_cond_destroy(3p) documentation says that:

> It shall be safe to destroy an initialized condition variable upon
> which no threads are currently blocked. Attempting to destroy a
> condition variable upon which other threads are
> currently blocked results in undefined behavior.

Let's make sure that this is the case by locking the associated mutex.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants