GCVCALLP-127: OpenSIPS 3.6, pulling in upstream #127
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(cherry picked from commit 9f3b78a)
(cherry picked from commit 9b8c8ed)
This prevents a crash running the child_init in the same time with a reload Many thanks go to ConnexCS for reporting and testing the fix! (cherry picked from commit ab3ffa1)
Per documentation: "To be more specific, the only runtime table we have so far is the "cc_calls" table." (cherry picked from commit 69ad46c)
(cherry picked from commit 65fc660)
(cherry picked from commit 7fcf09d)
The package distutils was deprecated in Python 3.10 and removed in 3.12. Let's switch to modern alternative. Also remove one extra shell call. Signed-off-by: Peter Lemenkov <lemenkov@gmail.com> (cherry picked from commit 5a986df)
Fix various function or variable type mismatch (cherry picked from commit be32aca)
It is possible that we can jump to `error` where we free `nt_name` right
before initialization. So better to initialize it first.
```
Compiling app_opensips/avps.c
gcc -fPIC -DPIC -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -DMOD_NAME='aaa_diameter' -DPKG_MALLOC -DSHM_MMAP -DUSE_MCAST -DDISABLE_NAGLE -DSTATISTICS -DHAVE_RESOLV_RES -DF_MALLOC -DQ_MALLOC -DHP_MALLOC -DDBG_MALLOC -DF_PARALLEL_MALLOC -DHAVE_STDATOMIC -DHAVE_GENERICS -DNAME='"opensips"' -DVERSION='"3.6.0"' -DARCH='"x86_64"' -DOS='"linux"' -DCOMPILER='"gcc 15"' -D__CPU_x86_64 -D__OS_linux -D__SMP_yes -DCFG_DIR='"/etc/opensips/"' -DVERSIONTYPE='"git"' -DTHISREVISION='"07da80880"' -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -c app_opensips/avps.c -o app_opensips/avps.o
app_opensips/avps.c: In function ‘parse_attr_def’:
app_opensips/avps.c:732:9: warning: ‘nt_name’ may be used uninitialized [-Wmaybe-uninitialized]
732 | free(nt_name);
| ^~~~~~~~~~~~~
app_opensips/avps.c:564:22: note: ‘nt_name’ was declared here
564 | char *name, *nt_name, *newp, *p = line, *end = p + len;
| ^~~~~~~
```
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
(cherry picked from commit 233769b)
Variable `old_state` can be used w/o being initialized. This patch fixed
it.
```
Compiling sharing_tags.c
gcc -fPIC -DPIC -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -DMOD_NAME='clusterer' -DPKG_MALLOC -DSHM_MMAP -DUSE_MCAST -DDISABLE_NAGLE -DSTATISTICS -DHAVE_RESOLV_RES -DF_MALLOC -DQ_MALLOC -DHP_MALLOC -DDBG_MALLOC -DF_PARALLEL_MALLOC -DHAVE_STDATOMIC -DHAVE_GENERICS -DNAME='"opensips"' -DVERSION='"3.6.0"' -DARCH='"x86_64"' -DOS='"linux"' -DCOMPILER='"gcc 15"' -D__CPU_x86_64 -D__OS_linux -D__SMP_yes -DCFG_DIR='"/etc/opensips/"' -DVERSIONTYPE='"git"' -DTHISREVISION='"07da80880"' -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -c sharing_tags.c -o sharing_tags.o
sharing_tags.c: In function ‘shtag_activate’:
sharing_tags.c:746:49: warning: ‘old_state’ may be used uninitialized [-Wmaybe-uninitialized]
746 | if (ret==SHTAG_STATE_ACTIVE && old_state!=SHTAG_STATE_ACTIVE) {
sharing_tags.c:685:18: note: ‘old_state’ was declared here
685 | int ret, old_state;
| ^~~~~~~~~
```
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
(cherry picked from commit 1c31a68)
GCC erroneously believes that `job_data` may be used uninitialized.
Let's help him understand the situation better.
```
Compiling kafka_producer.c
gcc -fPIC -DPIC -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -DMOD_NAME='event_kafka' -DPKG_MALLOC -DSHM_MMAP -DUSE_MCAST -DDISABLE_NAGLE -DSTATISTICS -DHAVE_RESOLV_RES -DF_MALLOC -DQ_MALLOC -DHP_MALLOC -DDBG_MALLOC -DF_PARALLEL_MALLOC -DHAVE_STDATOMIC -DHAVE_GENERICS -DNAME='"opensips"' -DVERSION='"3.6.0"' -DARCH='"x86_64"' -DOS='"linux"' -DCOMPILER='"gcc 15"' -D__CPU_x86_64 -D__OS_linux -D__SMP_yes -DCFG_DIR='"/etc/opensips/"' -DVERSIONTYPE='"git"' -DTHISREVISION='"07da80880"' -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -DWITH_GZFILEOP -c kafka_producer.c -o kafka_producer.o
kafka_producer.c: In function ‘kafka_report_status’:
kafka_producer.c:422:57: warning: ‘job_data’ may be used uninitialized [-Wmaybe-uninitialized]
422 | if (p->job->type == KAFKA_JOB_SCRIPT && job_data->report_rt)
| ~~~~~~~~^~~~~~~~~~~
kafka_producer.c:382:28: note: ‘job_data’ was declared here
382 | script_job_data_t *job_data;
| ^~~~~~~~
```
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
(cherry picked from commit 9472e64)
GCC erroneously believes that `hdrs` may be used uninitialized. Let's
help him understand the situation better.
```
Compiling http2d.c
gcc -fPIC -DPIC -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -DMOD_NAME='http2d' -DPKG_MALLOC -DSHM_MMAP -DUSE_MCAST -DDISABLE_NAGLE -DSTATISTICS -DHAVE_RESOLV_RES -DF_MALLOC -DQ_MALLOC -DHP_MALLOC -DDBG_MALLOC -DF_PARALLEL_MALLOC -DHAVE_STDATOMIC -DHAVE_GENERICS -DNAME='"opensips"' -DVERSION='"3.6.0"' -DARCH='"x86_64"' -DOS='"linux"' -DCOMPILER='"gcc 15"' -D__CPU_x86_64 -D__OS_linux -D__SMP_yes -DCFG_DIR='"/etc/opensips/"' -DVERSIONTYPE='"git"' -DTHISREVISION='"07da80880"' -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -I/usr/include -c http2d.c -o http2d.o
http2d.c: In function ‘h2_send_response’:
http2d.c:267:25: warning: ‘hdrs’ may be used uninitialized [-Wmaybe-uninitialized]
267 | for (it = hdrs->child; it; it = it->next, nh++, r->hdrs_len++) {
| ~~~^~~~~~~~~~~~~
http2d.c:138:16: note: ‘hdrs’ was declared here
138 | cJSON *hdrs, *it;
| ^~~~
```
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
(cherry picked from commit 19e2fac)
Completes OpenSIPS#3690 (cherry picked from commit c25a8ff)
Many thanks to Nuno Ferreira from Five9 for spotting, reporting and fixing this. (cherry picked from commit cc11d0a)
(cherry picked from commit 2702ead)
(cherry picked from commit a1ef1d8)
(cherry picked from commit 380c064)
When an update command is received, the dialog is searched: before this commit, if the dialog was not found, `dlg` was returned as `null`, and a new dialog, **with the same coordinates** was created. This commit makes sure that the dialog is no longer created if already in deleted state, thus avoiding creating the dialog multiple times with the same coordinates.
The "$sdp = NULL;" statement wasn't fully working as expected, as subsequent operations would still pick up some left-over SDP data. (cherry picked from commit 020ea0d)
OpenSIPS no longer throws an error on SDP bodies with missing line-termination sequence on the very last line. According to SDP ABNF specs, this is bad syntax, but we accept it and move on. Moreover, assuming the SDP is dirty (at least one edit), the output SDP ($sdp) will always be normalized to include the ending LF sequence. (cherry picked from commit 20b0ba8)
(cherry picked from commit c5fd8ad)
Make sure we are not trying to access the RTP context that has been destroyed along with the dialog moving in state 5. (cherry picked from commit bbfa2b0)
(cherry picked from commit b5d00aa)
If a final 200 OK reply was already sent, do not sent the 487 Request Terminated, but rather release the transaction (to stop retrasnmissions) (cherry picked from commit 203d8c9)
(cherry picked from commit f7721b1)
closes OpenSIPS#3779 (cherry picked from commit ec816e4)
(cherry picked from commit 9f78fd0)
If the dialog struct is removed from the timer list (and under processing by the timer), do not attempt to free it here, rather leave it alone, it will be freed by the timer (cherry picked from commit f5f11af)
As we have multiple procs reading from the same datagram sockets, we may end up with a mixing between the procs woken up by OS and the procs doing the reading. So some procs (even if were woken up) may have nothing to read. To be resilient, better do non-blocking reading and igonre the EAGAIN or EWOULDBLOCK. (cherry picked from commit 12e705e)
Also, fix top-level rc from "-1" (invalid user? continue script?) into "0" (auto-reply SIP 500 error! halt script!) on such scripting errors. Fixes OpenSIPS#3756 (cherry picked from commit dfd616b)
* fixes the build on 3.6 branch, due to old Clang (see commit e6caba0) * the rtp.io code is identical on 3.6 and master branches, no need to run duplicate checks. If it diverges, we can revert this commit.
(cherry picked from commit b88203c)
This commit prevents SIP replies from being absorbed (bug?!) by OpenSIPS after a launch() operation from onreply_route, with no further replies to upstream side on that T. Follow-up on a711924, see tm/t_reply.c. Such launch() calls are completely decoupled from the T, do not interfere with the script logic and can safely be done in parallel. (cherry picked from commit 11e37d1)
Since B2B destroys before tm, this should help prevent some shutdown crashes in B2B due to cascaded module cleanups (e.g. tm cleanups going into dialog, siprec then back again into B2B). (cherry picked from commit c482249)
In such case, mark the conn as timed out, to force its sending back to TCP main for closing. Also fix some bad ref counting when handling bad cons in ASYNC WRITE. Add more hist logs to conn, to easy the debugging process. (cherry picked from commit 4afd1c8)
benceszigeti
requested review from
DHennessyGenesys,
SubhashC37,
bcnewlin,
davidtrihy-genesys and
sekharp-genesys
bcnewlin
approved these changes
Jan 21, 2026
Collaborator
|
My sipmsg_validate and contact header dialog fix have been merged upstream with slight changes so if you could pull those in and defer to the new changes before merging. There's also the issue of the rest client updates that can cause the client to behave in a synchronous manner which will probable cause even more issue with internal TLS on here is the line I've identified as the main culprit https://github.com/purecloudlabs/opensips/blob/master/modules/rest_client/rest_methods.c#L976C25-L976C32 The issue seems to be it thinks that the request has already been serviced so it goes into a synchronous mode which is desired behaviour if that is the case but in the scenario where this happens it's not actually ready to download the body and it blocks The offending line is here https://github.com/purecloudlabs/opensips/blob/master/modules/rest_client/rest_methods.c#L910C29-L910C50 where req_sz can be 0 before the actual request has been serviced I think I have a potential fix for it without merging in my big PR changes which could be risky |
davidtrihy-genesys
approved these changes
Jan 23, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.