### 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