Date: Thu, 15 Feb 2018 16:54:42 +0100 From: Per olof Ljungmark <peo@nethead.se> To: freebsd-questions@freebsd.org Subject: Re: which limit is hit here? Message-ID: <8ff3e3d7-6861-313f-9689-10bb7eccf779@nethead.se> In-Reply-To: <CADqw_gKS=%2Be=PCgG6OJVfbuSwWD4zioZ__gnVNc5hYtM2Mfo%2Bg@mail.gmail.com> References: <d4d1093d-0db2-baed-0fb5-04b5127c8ccb@nethead.se> <CADqw_gKS=%2Be=PCgG6OJVfbuSwWD4zioZ__gnVNc5hYtM2Mfo%2Bg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/15/18 08:56, Michael Schuster wrote: > Hi Per, > > On Thu, Feb 15, 2018 at 8:41 AM, Per olof Ljungmark <peo@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8ff3e3d7-6861-313f-9689-10bb7eccf779>