Dependency Graph
View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004834 | SOGo | sogo-tool | public | 2019-09-30 09:59 | 2019-10-25 15:10 |
Reporter | sascha.kasch@sumcumo.com | Assigned To | ludovic | ||
Priority | normal | Severity | minor | Reproducibility | random |
Status | resolved | Resolution | duplicate | ||
Product Version | 4.0.8 | ||||
Summary | 0004834: update-autoreply fails with segmenation fault | ||||
Description | currently every daily cron with sogo-tool aupdate-autoreply fails with: <0x0x322ccf0[SOGoCache]> Cache cleanup interval set every 300.000000 seconds When triggered manually it also fails on first run but subsequent runs succeed. Looks like this fails when not being triggered for some time. Current SOGo: 4.0.8.20190923-1 | ||||
Tags | No tags attached. | ||||
now with 4.0.8.20191007-1 it fails all the time |
|
attached gdb via: gdb --args /usr/sbin/sogo-tool -v update-autoreply -p /opt/sogo/sieve-creds <0x0x18afce0[SOGoCache]> Cache cleanup interval set every 300.000000 seconds Program received signal SIGSEGV, Segmentation fault. |
|
and: 0005490 0x00007ffff676d998 in -[NSObject(SoObject) authenticatorInContext:] (self=0x1f0f020, _cmd=0x7fffeb2181d0 <_OBJC_SELECTOR_TABLE+1776>, _ctx=0x1d9f950) at SoObject.m:192 |
|
interesting: the above was wrong (first run was without any loaded shared libs): so again: gdb --args /usr/sbin/sogo-tool -v update-autoreply -p /opt/sogo/sieve-creds [Thread debugging using libthread_db enabled] [Inferior 1 (process 22564) exited normally] |
|
a normal run without gdb is also successfull... will wait a few hours and debug again |
|
I see this behavior as well. It occurs only when a user has enabled the out of office since it was last run and does not recur subsequently. It does not recur when OOO is disabled. |
|
GDB still throws: <0x0x122a6c0[SOGoCache]> Cache cleanup interval set every 300.000000 seconds Program received signal SIGSEGV, Segmentation fault. |
|
When it crashes, produce a stack trace by typing "bt". It works for me so I can't reproduce the issue right now. |
|
I can reproduce 4846 and it's the same bug, closing. |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2019-09-30 09:59 | sascha.kasch@sumcumo.com | New Issue | |
2019-10-07 20:05 | sascha.kasch@sumcumo.com | Note Added: 0013813 | |
2019-10-24 06:25 | sascha.kasch@sumcumo.com | Note Added: 0013838 | |
2019-10-24 06:28 | sascha.kasch@sumcumo.com | Note Added: 0013839 | |
2019-10-24 06:35 | sascha.kasch@sumcumo.com | Note Added: 0013840 | |
2019-10-24 06:36 | sascha.kasch@sumcumo.com | Note Added: 0013841 | |
2019-10-25 07:12 | veaseym | Note Added: 0013849 | |
2019-10-25 07:15 | sascha.kasch@sumcumo.com | Note Added: 0013850 | |
2019-10-25 14:51 | ludovic | Note Added: 0013852 | |
2019-10-25 15:10 | ludovic | Note Added: 0013853 | |
2019-10-25 15:10 | ludovic | Relationship added | duplicate of 0004846 |
2019-10-25 15:10 | ludovic | Status | new => resolved |
2019-10-25 15:10 | ludovic | Resolution | open => duplicate |
2019-10-25 15:10 | ludovic | Assigned To | => ludovic |