Call to nc_recv_reply is causing SIGABRT (libnetconf2 version is 2.1.25)

[krishnamohandasu]

Call to nc_recv_reply is causing signal abort in realloc function.

#2 0x0000007fb8b8a37c in __GI_raise (sig=sig@entry=6) at /usr/src/debug/glibc/2.38+git-r0/sysdeps/posix/raise.c:26
#3 0x0000007fb8b76f24 in __GI_abort () at abort.c:79
#4 0x0000007fb8bc2358 in __libc_message (fmt=fmt@entry=0x7fb8c9b7b0 "\204\212")
at /usr/src/debug/glibc/2.38+git-r0/sysdeps/posix/libc_fatal.c:150
#5 0x0000007fb8bd7928 in malloc_printerr (str=str@entry=0x7fb8c96d80 "\2762H\211\361A\366Dp\001 t$H\215B\001\017\037\200")
at malloc.c:5765
#6 0x0000007fb8bda90c in _int_malloc (av=av@entry=0x7fb8ce0a50 <main_arena>, bytes=bytes@entry=2033) at malloc.c:4071
#7 0x0000007fb8bdb444 in _int_realloc (av=av@entry=0x7fb8ce0a50 <main_arena>, oldp=oldp@entry=0x2dee13c0,
oldsize=oldsize@entry=1024, nb=nb@entry=2048) at malloc.c:4968
#8 0x0000007fb8bdc79c in __GI___libc_realloc (oldmem=0x2dee13d0, bytes=2028) at malloc.c:3510
#9 0x0000007fa420cbec in ?? ()
from /var/fpwork/workspace_manon/crash_debug/install_dir/sysroots/aarch64-linux-gnu/usr/lib64/libnetconf2.so.3
#10 0x0000007fa4216680 in ?? ()
from /var/fpwork/workspace_manon/crash_debug/install_dir/sysroots/aarch64-linux-gnu/usr/lib64/libnetconf2.so.3
#11 0x0000007fa42187ac in nc_recv_reply ()

nc_recv_reply signature being used is below

NC_MSG_TYPE nc_recv_reply | ( | struct nc_session * | session, -- | -- | -- | --   |   | struct nc_rpc * | rpc,   |   | uint64_t | msgid,   |   | int | timeout,   |   | struct lyd_node ** | envp,   |   | struct lyd_node ** | op   | ) |  

nc_recv_reply ( struct nc_session * session,
struct nc_rpc * rpc,
uint64_t msgid,
int timeout,
struct lyd_node ** envp,
struct lyd_node ** op
)

[michalvasko]

I expect some invalid parameters. Try compiling libnetconf2 with debug symbols and then using valgrind to run your app.

[krishnamohandasu]

Upon further observations, we find netopeer server is sending reply in multiple chunks. In libnetconf library, is it possible to allocate bigger block of memory to avoid reallocating memory when the reply is coming multiple chunks?

[krishnamohandasu]

So you mean even if the reply packet size is 65536 bytes (65KB) all the reply data except the meta data would be read in single recv_msg or recv socket call ?

Also, I would like to know how to control the size of packet exchanged between netopeer2 server and netconf client ? In our application, even though application didn't set any size, the packet size is not exceeding more 1116 Bytes ?

[michalvasko]

Yes, nc_read_chunk() is used instead of nc_read_until().

It seems WRITE_BUFSIZE is used to decide the maximum size of outgoing chunks, which is 2 * BUFFERSIZE. It can be adjusted but I am not sure how exactly.

[krishnamohandasu]

1. 2 * BUFFERSIZE you were telling from netconf client side. But from Netopeer server itself sending 1 KB packets. Is there any possibility to control the length of the packet to higher size using nc_XX API ?

2. Just to reiterate on the above back trace, crash is due to SIGABRT (raised due to abort() call from malloc library call from libc). So this issue might have happened while allocating memory to parse the metadata of reply or while allocating the memory to recv chunk (remaining bytes in the reply) right ?

3. Also please confirm if below understanding is correct.
   When application invokes nc_recv_reply libary call
   i) Allocate 512 byte block (based on BUFFERSIZE macro definition) to read meta data
   ii) Allocate memory block based on the size of the message received in the meta data and then read the remaining bytes in the message using single recv/recvMsg call right ?

[michalvasko]

1. No, it should be any writer that uses that buffer length, it is irrelevant whether it is a NETCONF server or client. And no, there is no API, the macros control these sizes currently.
2. Obviously while allocating some memory for the reply, I cannot tell you more.
3. Yes, that should be pretty much what is happening.

It seems you are using an old version of libnetconf2 so my suggestion would be to upgrade, it is definitely the time and you may avoid this problem and possibly other ones.

[krishnamohandasu]

Thank for you sharing your thoughts. We will to continue to check further.