Am 25.09.26 um 12:57 schrieb Frank Richter:
Am 24.09.26 um 14:48 schrieb Andreas Piesk:
Am 24.09.26 um 13:48 schrieb Frank Richter:
But how to find the cause of the segfault … any hints welcome.
enable core dumps. after a segfault get a backtrace on the dump. binary should not be stripped, symbols are needed. if you can, compile the code with debug info.
On Debian 13 with systemd I installed systemd-coredump and dbgsym and src packages.
Then coredumpctl info <pid> shows:
Signal: 11 (SEGV)
Timestamp: Fri 2026-09-25 11:16:18 CEST (1h 21min ago)
Command Line: imapd -U 250
Executable: /usr/lib/cyrus/bin/imapd
…
Message: Process 2916244 (imapd) of user 109 dumped core.
Module libzstd.so.1 from deb libzstd-1.5.7+dfsg-1.amd64
Module libuuid.so.1 from deb util-linux-2.41.5-0+deb13u1.amd64
Module libgcc_s.so.1 from deb gcc-14-14.2.0-19.amd64
Module libstdc++.so.6 from deb gcc-14-14.2.0-19.amd64
Stack trace of thread 2916244:
#0 0x00007f7c6d27b0b8 prot_vprintf (libcyrus.so.0 + 0x9e0b8)
#1 0x00007f7c6d27b208 prot_printf (libcyrus.so.0 + 0x9e208)
#2 0x000055b50b0fe826 cmd_enable (/usr/lib/cyrus/bin/imapd +
0x17826)
#3 0x000055b50b119aeb cmdloop (/usr/lib/cyrus/bin/imapd +
0x32aeb)
#4 0x000055b50b11e1cb service_main (/usr/lib/cyrus/bin/imapd
+ 0x371cb)
#5 0x000055b50b0f6fac main (/usr/lib/cyrus/bin/imapd + 0xffac)
#6 0x00007f7c6c635ca8 n/a (libc.so.6 + 0x29ca8)
#7 0x00007f7c6c635d65 __libc_start_main (libc.so.6 + 0x29d65)
#8 0x000055b50b0f7631 _start (/usr/lib/cyrus/bin/imapd +
0x10631)
ELF object binary architecture: AMD x86-64
coredumpctl debug <pid> … opens gdb
(gdb) backtrace
#0 0x00007f7c6d27b0b8 in prot_vprintf (s=0x0, fmt=0x55b50b1347dc "%s ENABLE",
pvar=pvar@entry=0x7ffcb5d3d5f0)
at lib/prot.c:1298
#1 0x00007f7c6d27b208 in prot_printf (s=<optimized out>, fmt=fmt@entry=0x55b50b1347dc
"%s ENABLE")
at lib/prot.c:1288
#2 0x000055b50b0fe826 in cmd_enable (tag=0x55b51361fb10 "6") at
imap/imapd.c:14537
#3 0x000055b50b119aeb in cmdloop () at imap/imapd.c:1775
#4 0x000055b50b11e1cb in service_main (argc=<optimized out>, argv=<optimized
out>, envp=envp@entry=0x7ffcb5d404f8)
at imap/imapd.c:1209
#5 0x000055b50b0f6fac in main (argc=<optimized out>, argv=<optimized out>,
envp=0x7ffcb5d404f8)
at master/service.c:647
in prot_vprintf s == NULL!
in prot_printf s == NULL!
in cmd_enable prot_printf(be->out, … be->out is == NULL
(gdb) print *be shows the according backend server (we have a murder), but
out == NULL. So no backend connection?
The client (SOGo webmail) sends: 6 ENABLE QRESYNC
The server runs cyrus-imapd-3.10.3 (self build with Debian patches), 2
frontends, 2 backend servers, 1 mupdate master (on frontend).
I guess, no backend connection anymore. I'm nore sure why, but olny cmd_enable
walks backend_cache isntead if using proxy_findserver():
if (ptrarray_size(&backend_cached)) {
for (int i = 0; i < ptrarray_size(&backend_cached); i++) {
struct backend *be = ptrarray_nth(&backend_cached, i);
prot_printf(be->out, "%s ENABLE", tag);
the problem is, the Backend connection can be dropped (out = NULL) but the
entry is not removed. you could try to increase the idle limit as a workaorund.
-ap
------------------------------------------
Cyrus: Info
Permalink:
https://cyrus.topicbox.com/groups/info/T9e1e24185b6d5bc3-Maa641ae31953a4e778280cd0
Delivery options: https://cyrus.topicbox.com/groups/info/subscription
