Hi @miconda ,
thanks for your feedback!
Regarding `ksr_logdata_t`, most likely it got flagged by some static checker, but we've re-tested the original version and couldn't pin-point which exact check/rule triggered this.
Regarding the `asprintf` - thanks for spotting the memory leak! We've never detected it using our memory checkers since we never actually use the default stub continuously - it always gets replaces when our custom module is initialised.
Then, when this new mechanism is used and what is the benefit? Can you provide some examples?
The benefits of being able to control the output format of the logs are mainly evident when Kamailio is used in a deployment alongside other products/tools, all of which are generating their logs using a common scheme. Thus, being able to control Kamailio log output scheme helps to: 1. keep the log collection/processing pipeline manageable (since all logs flowing through it share a common scheme) 2. reduce the developer cognitive load from having to switch to different log formats during development stage (not dealing with production logs from log pipeline but with direct Kamailio output)
Here's a sample output made possible with the help of this patch: (scheme used: `<pname> <ver> <timestamp> <lvl> <mname> <pid>:<file>:<line> <msg>`) ``` pname 1.35.15 2024-06-20T10:43:24.134886Z WARNING pname 13:libpname/core.cpp:85 Core successfully created! pname 1.35.15 2024-06-20T10:43:24.135058Z INFO tls 13:tls_mod.c:445 use OpenSSL version: 30000070 pname 1.35.15 2024-06-20T10:43:24.135079Z INFO tls 13:tls_mod.c:447 With ECDH-Support! pname 1.35.15 2024-06-20T10:43:24.135096Z INFO tls 13:tls_mod.c:450 With Diffie Hellman pname 1.35.15 2024-06-20T10:43:24.135166Z WARNING tls 13:tls_init.c:980 openssl bug #1491 (crash/mem leaks on low memory) workaround enabled (on low memory tls operations will fail preemptively) with free memory thresholds 11534336 and 5767168 bytes pname 1.35.15 2024-06-20T10:43:24.135203Z INFO core 13:core/cfg/cfg_ctx.c:589 tls.low_mem_threshold1 has been changed to 11534336 pname 1.35.15 2024-06-20T10:43:24.135223Z INFO core 13:core/cfg/cfg_ctx.c:589 tls.low_mem_threshold2 has been changed to 5767168 ... pname 1.35.15 2024-06-20T10:43:24.136142Z INFO tls 13:tls_mod.c:491 Loading SSL_CTX in process_no=0 rank=-127 ksr_tls_threads_mode=0 pname 1.35.15 2024-06-20T10:43:24.136176Z INFO tls 13:tls_domain.c:353 TLSs<default>: tls_method=23 pname 1.35.15 2024-06-20T10:43:24.136200Z INFO tls 13:tls_domain.c:365 TLSs<default>: certificate='/usr/local/lib/pname/certs/serv.crt' ... pname 1.35.15 2024-06-20T10:43:33.612026Z TRACE pname 16:libpname/log/trace_object.hpp:19 Create > binding::SipMsg() pname 1.35.15 2024-06-20T10:43:33.612093Z TRACE pname 16:libpname/binding/sip_msg.cpp:645 Call > binding::SipMsg::getCallId() pname 1.35.15 2024-06-20T10:43:33.612136Z TRACE pname 16:libpname/log/logger.cpp:100 Call > zroute::Logger::setTraceId("3811ef5eb36d7024f1f3e7bfaf70e572") pname 1.35.15 2024-06-20T10:43:33.612194Z INFO pname 16:/usr/local/etc/pname/./route.cfg:11 TraceID[3811ef5eb36d7024f1f3e7bfaf70e572] Processing "INVITE" request received from "sip:10.22.10.9:5060" [Call-Id: "8t1b49///1-94@10.22.10.9"] pname 1.35.15 2024-06-20T10:43:33.612218Z INFO debugger 16:debugger_api.c:351 TraceID[3811ef5eb36d7024f1f3e7bfaf70e572] request_route=[DEFAULT_ROUTE] c=[/usr/local/etc/pname/./route.cfg] l=12 a=25 n=MYLOG_DBG pname 1.35.15 2024-06-20T10:43:33.612244Z TRACE pname 16:libpname/log/logger.cpp:110 TraceID[3811ef5eb36d7024f1f3e7bfaf70e572] Call > zroute::Logger::isTraceIdSet() pname 1.35.15 2024-06-20T10:43:33.613788Z DEBUG pname 16:/usr/local/etc/pname/././invite.cfg:2 TraceID[3811ef5eb36d7024f1f3e7bfaf70e572] Received INVITE request, routing pname 1.35.15 2024-06-20T10:43:33.612266Z DEBUG pname 16:/usr/local/etc/pname/./route.cfg:12 TraceID[3811ef5eb36d7024f1f3e7bfaf70e572] INVITE sip:test@example.com SIP/2.0 ```