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.

Sign up for GitHub

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

Jump to bottom

Is this supported on Mac OS X? #1

Closed
ghost opened this issue May 27, 2016 · 1 comment
Closed

Is this supported on Mac OS X? #1

ghost opened this issue May 27, 2016 · 1 comment
Assignees
@rkrejci
Labels
is:question Issue is actually a question.

Comments

@ghost
Copy link

ghost commented May 27, 2016

Will I be able to use libnetconf2 on Mac OS X? Is there intent to support this on Mac OS X?

Thanks,
@rkrejci rkrejci added the is:question Issue is actually a question. label May 30, 2016
@rkrejci
Copy link
Collaborator

rkrejci commented May 30, 2016

Hi, we can help with solving the issue. But since we don't use/test it on OS X, our capabilities to e.g. debug and search for a bug are very limited.

@rkrejci rkrejci closed this as completed May 30, 2016
jktjkt added a commit to jktjkt/libnetconf2 that referenced this issue Nov 21, 2016
@jktjkt
Fix memleak in OpenSSL uninitialization
7361b98 
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
@jktjkt
Fix memleak in OpenSSL uninitialization
47e9e1a 
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
@jayshankarnair jayshankarnair mentioned this issue Apr 4, 2018
Closed
@rovarga rovarga mentioned this issue Aug 10, 2018
Closed
@RavikumarTulugu RavikumarTulugu mentioned this issue Sep 26, 2018
Closed
rjarry added a commit to 6WIND/libnetconf2 that referenced this issue Oct 10, 2018
@rjarry
session: fix lock on wrong mutex
54ea296 
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>
@shishirpandey29 shishirpandey29 mentioned this issue Oct 15, 2018
Closed
@vishalearnz vishalearnz mentioned this issue Sep 25, 2019
Closed
@fengzeroz fengzeroz mentioned this issue Aug 26, 2020
Closed
@tcnyambira tcnyambira mentioned this issue Oct 1, 2020
Closed
@Rohit2387 Rohit2387 mentioned this issue Dec 1, 2020
Closed
@rohitkathuria102 rohitkathuria102 mentioned this issue Jun 8, 2021
Closed
jktjkt added a commit to jktjkt/libnetconf2 that referenced this issue Oct 8, 2021
@jktjkt
Use getpwuid_r() instead of getpwuid()
45728b2 
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
@jktjkt @michalvasko
Use getpwuid_r() instead of getpwuid()
6aa0eeb 
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
@jktjkt
Fix segfault on malformed yang-library data
56adf5a 
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
@jktjkt @michalvasko
Fix segfault on malformed yang-library data
1d73a5a 
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.
@tieliao tieliao mentioned this issue Mar 24, 2023
Merged
@kaizhang0124 kaizhang0124 mentioned this issue Aug 11, 2023
Closed
@awesomenode awesomenode mentioned this issue Mar 4, 2024
Closed
@awesomenode awesomenode mentioned this issue Mar 19, 2024
Closed
jktjkt added a commit to jktjkt/libnetconf2 that referenced this issue Apr 10, 2024
@jktjkt
TSAN: don't race through pthread_cond_destroy
e0653f8 
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
@jktjkt @michalvasko
TSAN: don't race through pthread_cond_destroy
fd3a01d 
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
Assignees

@rkrejci rkrejci

Labels
is:question Issue is actually a question.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@rkrejci