Panic: data stack: Out of memory when allocating bytes

[Josef 'Jeff' Sipek]

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