On Wed, Jan 24, 2018 at 18:55:47 +0100, Thomas Robers wrote: > Am 23.01.2018 um 20:07 schrieb Josef 'Jeff' Sipek: > > On Tue, Jan 23, 2018 at 14:03:27 -0500, Josef 'Jeff' Sipek wrote: > > > On Tue, Jan 23, 2018 at 18:21:38 +0100, Thomas Robers wrote: ... > > > 1. Do you have any idea what the imap process was doing at the time of the > > > allocation failure? > > Yes perhaps. We use shared mailboxes and at the time of failure the > imap process is reading acl files in a shared mailbox (and subfolder). > This shared mailbox has about 2800 subfolder and the acl files are read > in about 10sec and and during this reading the imap process dies with > the already mentioned error. It seems it has something to do with the > shared mailbox, because since yesterday morning 5 core dumps have been > created, 4 of them by one user accessing the shared mailbox and 1 > by the user who is the owner of the shared mailbox. No other mailboxes > are affected until now.
Based on the stack trace, the client was creating a new mailbox, which caused an acl list rebuild, which ended up triggering this oddly sized allocation. > > > 2. You snipped all the important parts of the back trace. :) It *starts* > > > on > > > the line: > > > #0 0x00007f73f1386495 in raise () from /lib64/libc.so.6 > > > > In case you haven't used gdb before... after starting up gdb, run "bt full" > > at the gdb prompt. That'll print out a very detailed backtrace. (You might > > want to sanity check it to make sure there aren't any user passwords in it > > before posting it here...) > > Yes, sorry I'm not very familiar in using gdb, but here is the full > backtrace: It looks like the binaries are stripped. There should be a "debug" package you can install with symbol information. Then, the backtrace should be much more helpful. > > > Having the backtrace should help answer question number 1. > > > 3. How big is this process when it dies? > > I don't know which imap process dies beforehand so how do i get this > information? The size of the core file will give you an general idea. gdb can also print out lots of info via "maintenance info sections", but I don't think that'll help figuring out why things blow up. Jeff. -- Keyboard not found! Press F1 to enter Setup
