### Description
Hello,
When there is an error in my ruby script, app_ruby prints exception message without a stack trace, like this:
```
Dec 14 16:25:17 servername /usr/sbin/kamailio[24313]: ERROR: app_ruby [app_ruby_api.c:105]: app_ruby_print_last_exception(): exception: wrong number of arguments (1 for 2..3)
Dec 14 16:25:17 servername /usr/sbin/kamailio[24313]: ERROR: app_ruby [app_ruby_api.c:1078]: app_ruby_run_ex(): ruby exception (6) on callback for: ksr_request_route (res type: 17)
```
Altough this message tells what is the error, it doesn't tell **where** the error happened, so it's hard to find the source of the problem.
In ruby, exceptions have _backtrace()_ method returning stack trace as an array of strings. It would be really helpful if app_ruby also call this method and append its result to error message.
### Reproduction
in kamailio.cfg
```
loadmodule "app_ruby.so"
modparam("app_ruby", "load", "/etc/kamailio/ruby/routes.rb")
cfgengine "ruby"
```
in /etc/kamailio/ruby/routes.rb
```
def some_method(param1, param2)
end
def ksr_request_route
some_method(1)
end
```
### Expected behavior
```
Dec 14 16:46:24 servername /usr/sbin/kamailio[24314]: ERROR: <core> [core/kemi.c:87]: sr_kemi_core_err(): wrong number of arguments (1 for 2): /etc/kamailio/ruby/routes.rb:1:in `some_method'
/etc/kamailio/ruby/routes.rb:4:in `ksr_request_route'
```
#### Actual observed behavior
```
Dec 14 16:45:42 servername /usr/sbin/kamailio[24311]: ERROR: app_ruby [app_ruby_api.c:105]: app_ruby_print_last_exception(): exception: wrong number of arguments (1 for 2)
```
### Possible Solutions
Relevant code seem to be here: https://github.com/kamailio/kamailio/blob/master/src/modules/app_ruby/app_r…
I found example C code to print stack trace here but couldn't figure out how to integrate to app_ruby: http://zoo-project.org/svn/trunk/zoo-project/zoo-kernel/service_internal_ru…
Equivalent ruby code would be (this code is not idiomatic, my aim is to provide C-like ruby code):
```
def some_error_generating_method
method_taking_two_params(1)
rescue => exception
message = exception.to_s() + "\n"
stack_trace = exception.backtrace()
for line in stack_trace
message = message + line + "\n"
end
print(message)
end
```
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.2.0 (x86_64/linux) 535e13
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144 MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 535e13
compiled on 10:26:34 Nov 28 2018 with gcc 4.8.5
```
* **Operating System**:
Centos 7.2 64bit
```
Linux servername 3.10.0-327.28.2.el7.x86_64 #1 SMP Wed Aug 3 11:11:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1766
Hello,
following the Kamailio Developers Meeting discussions and provided that
GNU/Linux malloc() aligns allocated memory to 16 bytes on x86_64 (64b
CPUs), I just updated the native Kamailio qm (quick malloc - the default
one) and fm (fast malloc) memory managers to also align to 16 bytes:
-
https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.ht…
By default they do it to 16 also for 32b CPUs, the overhead at startup
with default config was rather insignificant (like 5000 bytes for
private memory set to 8MB), so I didn't want to bother that much (that's
also because some 32b CPUs could require larger alignment that the size
of the pointer address), but for flexibility I added the an option to
set the alignment size at compile time with KSR_MEMORY_ALIGN define
(e.g., -DKSR_MEMORY_ALIGN=8UL).
The main benefit at this moment is that Kamailio should be able to use
the OS distribution (e.g., Debian) packaged libwolfssl instead of
bundling and building the library inside it to compile with custom
flags, like it is done now. Also, it is safe for the future to use other
libraries that leverage internally the OS memory alignment size for
specific optimizations.
I also increased the optimize factor to 15, which should speed up a bit
dealing with larger chunks of memory (now up to 32KB, previously was up
to 16KB). Considering that it is more and more common to deal with
larger SIP messages (e.g., a webrtc invite can easily be like 20KB) as
well as tls/encryption needs addition space that the unencrypted udp/tcp.
Hopefully these updates don't have side effects, it was nothing
consistent changed, a few defines and fields to match the new alignment
constraints. But testing is important, try to play with the master and
your configs whenever you have any chance.
Unfortunately the tlsf memory manager seems to be specifically designed
for aligning to 8 bytes, a rather old related issue in that project is
not concluded:
- https://github.com/mattconte/tlsf/issues/16
That means the tls_wolfssl module linked with the officially packaged
libwolfssl has to be used with qm or fm malloc from now on. Or it has to
be built like so far to use tlsf memory manager. The tls/tlsa module can
still be used with tlsf memory manager.
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services
```
CC (gcc) [M ping_endpoint.so] t_cancel.o
CC (gcc) [M ping_endpoint.so] t_fifo.o
In file included from ../../core/ut.h:42,
from t_fifo.c:38:
t_fifo.c: In function 'append2buf':
../../core/dprint.h:321:73: warning: format '%i' expects argument of type 'int', but argument 11 has type 'long int' [-Wformat=]
321 | fprintf(stderr, "%2d(%d) %s: %.*s%s%s%s" fmt, \
| ^~~~~~~~~~~~~~~~~~~~~~~~
../../core/dprint.h:345:25: note: in expansion of macro 'LOG_FX'
345 | LOG_FX(facility, level, lname, prefix, _FUNC_NAME_, fmt, ## args)
| ^~~~~~
../../core/dprint.h:351:25: note: in expansion of macro 'LOG_FL'
351 | LOG_FL(facility, level, NULL, prefix, fmt, ## args)
| ^~~~~~
../../core/dprint.h:354:25: note: in expansion of macro 'LOG_FP'
354 | LOG_FP(DEFAULT_FACILITY, (level), LOC_INFO, fmt, ## args)
| ^~~~~~
../../core/dprint.h:401:45: note: in expansion of macro 'LOG'
401 | # define DBG(fmt, args...) LOG(L_DBG, fmt , ## args)
| ^~~
../../core/dprint.h:405:36: note: in expansion of macro 'DBG'
405 | # define DEBUG(fmt, args...) DBG(fmt , ## args)
| ^~~
../../core/dprint.h:422:16: note: in expansion of macro 'DEBUG'
422 | #define LM_DBG DEBUG
| ^~~~~
t_fifo.c:576:33: note: in expansion of macro 'LM_DBG'
576 | LM_DBG("AVP <%i>: %p\n",avp_name.n,avp);
| ^~~~~~
CC (gcc) [M ping_endpoint.so] t_funcs.o
CC (gcc) [M ping_endpoint.so] t_fwd.o
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3637
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3637(a)github.com>
Hello,
during the Kamailio Developers Meeting 2023 in Dusseldorf early this
week, Victor Seva shared how one can setup own development environment
for facilitating the automatic checks for clang-format and few other
useful bits (e.g., training white spaces) using pre-commit tool. So I
thought it would be useful to shared further to both developers and
users communities (as the later can make patches and pull requests as well).
If I forgot something, Victor should amend me, but the main steps are:
- install pre-commit package (either via apt or via pip3)
- install clang-format (debian/ubuntu should have it as a package)
- go to the folder with git clone of Kamailio source and run:
pre-commit install
The above command can take some time, but it is needed only once.
After that, on evey commit, the checks should be performed a summary
should be presented on screen, like:
$ git commit src/
check yaml...........................................(no files to
check)Skipped
check xml............................................(no files to
check)Skipped
fix end of
files.........................................................Passed
trim trailing
whitespace.................................................Passed
check for merge
conflicts................................................Passed
mixed line
ending........................................................Passed
clang-format.............................................................Passed
If the check of clang-format results in "Failed", like:
clang-format.............................................................Failed
the pre-commit hooks will correct it, so you can just run again the
commit command and the 2nd time should be good to go.
If for whatsoever reasons pre-commit is installed but you need to
ignore/skip the pre-commit hooks, just provide -n or --no-verify to the
commit command, like:
$ git commit -n src/
By using pre-commit hooks, one could easily avoid making pull requests
that are failing to meet the code formatting checks on github portal as
well as ensure that as developer one does no forget to run clang-format
before commit.
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services