search for: munmap

...opening mailboxes. Total time to open the box was about 1 minute. Upon truss'ing the imap process during an open, I saw the trace quoted below at the end of the email. As you can see, for each "FETCH" line of response, we were seeing dovecot do a ton of work-- mmaping anon, lots of munmaps(), etc. -- mmap() and munmap() are not free. The stack trace of at least one of the munmaps is captured below, as well-- deep inside of the mail caching code. Then, I moved aside the user's .imap directory, assuming that forcing dovecot to rebuild its indices and caches could help-- and sure...

...se(15)??????????????????????? = 0 190074 close(8)???????????????????????? = 0 190074 brk(0x7f99e469a000)????????????? = 0x7f99e469a000 190074 brk(0x7f99e4697000)????????????? = 0x7f99e4697000 190074 brk(0x7f99e4692000)????????????? = 0x7f99e4692000 190074 close(7)???????????????????????? = 0 190074 munmap(0x7f99df5ae000, 2106232)? = 0 190074 munmap(0x7f99df7b1000, 2190784)? = 0 190074 munmap(0x7f99df3a8000, 2118896)? = 0 190074 munmap(0x7f99df0f8000, 2817696)? = 0 190074 munmap(0x7f99deea7000, 2426160)? = 0 190074 munmap(0x7f99dec98000, 2155816)? = 0 190074 munmap(0x7f99dea7e000, 2201520)? = 0 19007...

...= 504* fstat(34, {st_mode=S_IFREG|0644, st_size=24713, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4d64ee9000 lseek(34, 0, SEEK_CUR) = 24713 write(34, "[2014/12/02 10:43:18.654245, 1]"..., 66) = 66 munmap(0x7f4d64ee9000, 4096) = 0 getpeername(28, 0x7fff5f0b8840, [128]) = -1 ENOTCONN (Transport endpoint is not connected) stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2593, ...}) = 0 *geteuid() = 504* fstat(34, {st_mode=S_IFREG|0644, st_si...

I observed several long running dovecot/lmtp processes hogging the CPU. I then strace'd them (strace -c -p 6375) and found them munmap()-ing a lot: % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 97.18 19.592537 1878 10430 munmap 2.28 0.458984 36 12696 epoll_ctl 0.26 0.052926 10 528...

Hi, Header says: /* * Unmaps the @count pages starting at @start_address, which were mapped by a * call to xc_gntshr_share_*. Never logs. */ int xc_gntshr_munmap(xc_gntshr *xcg, void *start_address, uint32_t count); But implementation calls: static int linux_gntshr_munmap(xc_gntshr *xcg, xc_osdep_handle h, void *start_address, uint32_t count) { return munmap(start_address, count); } munmap(2) expect second argument to be...

On Tue, Dec 16, 2014 at 03:40:08PM +0100, Nacho del Rey wrote: > Hi there > > In an Oracle RAC cluster using ACFS (as file-system) where we have a samba > server for sharing files to windows clients, we are suffering a strange > issue, from time to time, which it causes the Windows clients lock for a > while (10 min or a bit more) or even indefinitely when they are working >

I'm testing both sunfreeware and official sun (sfw) samba on Solaris 10. For some reason since yesterday, the smbd process just "hangs" at the start. No log is generated on server side Where smbd is started, I can't find any open port on 139 or 145 My OS is Solaris 10 # uname -a SunOS labo2 5.10 Generic_142900-13 sun4v sparc SUNW,SPARC-Enterprise-T5120 #

...= 1075892017 5113: fcntl(4, F_SETLKW64, 0xDFFFF5F8) = 0 5113: close(14) = 0 5113: time() = 1075892017 5113: close(9) = 0 5113: munmap(0xDF230000, 1608) = 0 5113: munmap(0xDF220000, 10264) = 0 5113: close(10) = 0 5113: munmap(0xDF1A0000, 1560) = 0 5113: close(12) = 0 5113: munmap...

Hi! Just updated to 1.0 rc15, but the problem remains. I think it could be client-dependent to some extent. I have only IMAPS access and Maildir. I have one mailbox which contains some 10,200 mails. That mailbox takes forever (have waited 30 minutes and then aborted) to open with Thunderbird 1.5.0.7. Other mailboxes (like dovecot :-), only 6984 mails) opens quickly. When Thunderbird tries to

Hi Xen folks! I''ve faced with one strange thing in ARM version of Xen: when I use xc_map_foreign_bulk() to map some memory from domU to dom0, after unmap() for previous returned address - memory is not freed at all. Let''s look at call stack: xc_map_foreign() -> linux_privcmd_map_foreign_bulk() -> { addr = mmap(fd); ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2 );

...ast night''s Xen snapshot (apr 24th), on kernel 2.6.12-rc3 - but the mess is so horrid that I''m not quite sure how to fix it... This oops prevents xen from starting xenU domains. Basically xend does the following: 1) mmap /proc/xen/privcmd 2) call an ioctl to populate the mmap 3) munmap the mapping created in (1) During the munmap, the dom0 kernel oopses, as follows: CPU: 0 EIP: 0061:[<c01505ed>] Not tainted VLI EFLAGS: 00010282 (2.6.11-1.1261_FC4.rielxen0) EIP is at set_page_dirty+0x1d/0x60 eax: 8b04ec83 ebx: c13da920 ecx: c13da920 edx: c025e1d0 esi: d4e0...

...It works fine on what is meant to be an identical system. I tried running strace and it seems to exit after trying to write to a bad file descriptor: rt_sigaction(SIGINT, {SIG_DFL}, {0x34f2c8d0b0, [INT], SA_RESTORER|SA_RESTART, 0x3dde2300b0}, 8) = 0 close(7) = 0 munmap(0x2aaaaaaad000, 4096) = 0 close(7) = -1 EBADF (Bad file descriptor) munmap(0x2aaaaaaac000, 4096) = 0 write(7, "\25\3\1\0 -\2040\17\311F \372bz\\\10Gi\2}\344\325S\247j\373\257`\361}b"..., 37) = -1 EBADF (Bad file descriptor) close(4)...

...MAP_PRIVATE, 3, 0) = 0xEF7C0000 open("/usr/lib/libsocket.so.1", O_RDONLY) = 4 fstat(4, 0xEFFFF83C) = 0 mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0xEF7B0000 mmap(0x00000000, 106496, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0xEF790000 munmap(0xEF798000, 57344) = 0 mmap(0xEF7A6000, 8185, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 24576) = 0xEF7A6000 mmap(0xEF7A8000, 388, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xEF7A8000 close(4) = 0 open(...

...OUS, -1, 0) = > 0x7f2f8db8a000 > read(30, "rootfs / rootfs rw 0 0\nnone /sys"..., 1024) = 1024 > read(30, "dered 0 0\n/dev/mapper/group-mate"..., 1024) = 649 > read(30, "", 1024) = 0 > close(30) = 0 > munmap(0x7f2f8db8a000, 4096) = 0 > munmap(0x7f2f8db8b000, 45774) = 0 > open("/lib/security/pam_smbpass.so", O_RDONLY) = -1 ENOENT (No such file > or directory) > read(29, "", 4096) = 0 > close(29) =...

...ening for a while now. I thought it would be good to report the issue. I ran an strace on one of them and this is the output: Process 21370 attached - interrupt to quit open("/var/run/dovecot/stats-mail", O_WRONLY) = 7 write(7, "DISCONNECT\ta09ade0350d81d517a530"..., 44) = 44 munmap(0x7f1ad8a8d000, 266240) = 0 close(13) = 0 close(12) = 0 epoll_ctl(9, EPOLL_CTL_DEL, 11, {0, {u32=17384128, u64=17384128}}) = 0 close(11) = 0 close(7) = 0 munmap(0x7f1ada...

..._READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x4000e000 mmap2(0x40119000, 74620, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x103) = 0x40119000 mmap2(0x4012c000, 10364, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4012c000 close(4) = 0 munmap(0x40007000, 4096) = 0 open("/lib/libutil.so.0", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=4656, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000 read(4, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0008\10...

...;], [/* 37 vars */]) = 0 brk(0) = 0x8107e88 open("/etc/ld.so.preload", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0 old_mmap(NULL, 2, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0x126000 close(3) = 0 munmap(0x126000, 2) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=69627, ...}) = 0 old_mmap(NULL, 69627, PROT_READ, MAP_PRIVATE, 3, 0) = 0x126000 close(3) = 0 open("/usr/lib/libssl.so.0.9.6",...

..._READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x4000e000 mmap2(0x40119000, 74620, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x103) = 0x40119000 mmap2(0x4012c000, 10364, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4012c000 close(4) = 0 munmap(0x40007000, 4096) = 0 open("/lib/libutil.so.0", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=4656, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000 read(4, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0008\10...

...S, -1, 0) = 0x7fa29ca43000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa29ca42000 arch_prctl(ARCH_SET_FS, 0x7fa29ca43700) = 0 mprotect(0x7fa29c07f000, 4096, PROT_READ) = 0 mprotect(0x7fa29c40a000, 16384, PROT_READ) = 0 mprotect(0x7fa29ca4e000, 4096, PROT_READ) = 0 munmap(0x7fa29ca46000, 25665) = 0 uname({sys="Linux", node="lb1.local", ...}) = 0 umask(0177) = 022 brk(0) = 0x1c57000 brk(0x1c78000) = 0x1c78000 open("/etc/conntrackd/conntrackd.conf&q...

...on, I was doing some testing of a little piece of code on my machine, and I was able to crash it. What this program does is, in effect something like (pseudo-code) for(i=0; i<100; i++) { fd=creat file-i truncate fd, 50M mmap fd close fd fill the mmaped file-i with some 50MB of data munmap file-i } for(i=0; i<100; i++) { unlink file-i } When I run this with file-i on my ext2 partition, I'm not able to hang my machine, if I run it on a (plain, no lvm or raid) ext3 partition, it is quite simple to get it to crash reproducibly. About the hardware: this is a dual P-II, with 25...