which limit is hit here?

[Michael Schuster]

Hi Per,

On Thu, Feb 15, 2018 at 8:41 AM, Per olof Ljungmark <peo at nethead.se> wrote:

> Hi,
>
> A process "squatter" from Cyrus-IMAP version 2.5.11 exits with signal
> 11. The purpose of the process is to create an index of the content in a
> mailbox.
>
> On large mailboxes, squatter coredumps, the final message from truss reads:
>
> mmap(0x0,700448768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
> 34783363072 (0x819400000)
> mmap(0x0,936334732,PROT_READ,MAP_SHARED,107,0x0) = 35483811840
> (0x843000000)
> SIGNAL 11 (SIGSEGV)
> process killed, signal = 11 (core dumped)
>

to me this looks like the error is happening *after* mmap() returned
successfully - most likely because "someone" miscalculates some pointer and
tries to access an unmapped address. Maybe (but that's conjecture),
PROT_READ is wrong here and someone is attempting to write to that mapped
region; I'm not 100% sure though whether that'd actually trigger SIGSEGV.

I'd suggest you do something like
$ gdb squatter core
(gdb) bt

and look at the output, and maybe go to the maintainers of Cyrus-IMAP...

HTH
Michael


> and a tempfile is produced, always same size:
> 3017208832 cyrus.squat.NEW
>
> Same result on 10.3 and 11-STABLE.
>
> Is there a knob to let squatter have the necessary resource to complete
> the indexing?
>
> Thanks,
>
> //per
>


-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'