which limit is hit here?
michaelsprivate at gmail.com
Thu Feb 15 07:57:01 UTC 2018
On Thu, Feb 15, 2018 at 8:41 AM, Per olof Ljungmark <peo at nethead.se> wrote:
> 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
> 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
> 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
and look at the output, and maybe go to the maintainers of Cyrus-IMAP...
> 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?
recursion, n: see 'recursion'
More information about the freebsd-questions