which limit is hit here?

[Per olof Ljungmark]

On 02/15/18 08:56, Michael Schuster wrote:
> 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)

Some ktrace output before crash if of any use, please let me know what
more info can be produced:

 49022 squatter RET   write 154/0x9a
 49022 squatter CALL  lseek(0x96,0,SEEK_SET)
 49022 squatter RET   lseek 0
 49022 squatter CALL  mmap(0,0x9a,0x1<PROT_READ>,0x1<MAP_SHARED>,0x96,0)
 49022 squatter RET   mmap 34366210048/0x80062c000
 49022 squatter CALL  munmap(0x80062c000,0x9a)
 49022 squatter RET   munmap 0
 49022 squatter CALL  close(0x96)
 49022 squatter RET   close 0
 49022 squatter CALL  write(0x6b,0x80f105000,0xf884)
 49022 squatter GIO   fd 107 wrote 4096 bytes

 49022 squatter RET   write 63620/0xf884
 49022 squatter CALL  lseek(0x6b,0,SEEK_SET)
 49022 squatter RET   lseek 0
 49022 squatter CALL
mmap(0,0x29c00000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,0xffffffff,0)
 49022 squatter RET   mmap 34636562432/0x810800000
 49022 squatter CALL
mmap(0,0x37cf558c,0x1<PROT_READ>,0x1<MAP_SHARED>,0x6b,0)
 49022 squatter RET   mmap 35337011200/0x83a400000
 49022 squatter PSIG  SIGSEGV SIG_DFL code=SEGV_ACCERR
 49022 squatter NAMI  "squatter.core"


> 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
>>
> 
> 

-- 
Per olof Ljungmark
+46 707 50 20 46
Nethead AB
Registered in Stockholm, Sweden
SE556815226701