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

An idea about 'nc_rpc_clb' #3

Closed
fanchanghu opened this issue Jul 20, 2016 · 0 comments
Closed

An idea about 'nc_rpc_clb' #3

fanchanghu opened this issue Jul 20, 2016 · 0 comments
Assignees
@rkrejci

Comments

@fanchanghu
Copy link
Contributor

Hi,
I have met a question about handling RPC request. I want to use one common callback for all my RPC requests (in my case, just dispatch all RPC request to sysrepo with sr_rpc_send). But now I must set the callback function pointer to lys_node for all RPC, so I think we should allow users to give a global callback for handling RPC request, and if this global callback is not set, we can get callback function from lys_node to make sure current API still works.
If you agree with this idea, I can work on it and push the code to you.
@fanchanghu fanchanghu mentioned this issue Jul 21, 2016
Merged
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
@RavikumarTulugu RavikumarTulugu mentioned this issue Sep 26, 2018
Closed
@shishirpandey29 shishirpandey29 mentioned this issue Oct 15, 2018
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
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
@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
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rkrejci @michalvasko @fanchanghu