search for: mmape

This problem is found in meego testing: http://bugs.meego.com/show_bug.cgi?id=6672 A file in btrfs is mmaped and the mmaped buffer is passed to pwrite to write to the same page of the same file. In btrfs_file_aio_write(), the pages is locked by prepare_pages(). So when btrfs_copy_from_user() is called, page fault happens and the same page needs to be locked again in filemap_fault(). The fix is to move io...

...range to me that it doesn't appear on other systems. I'll try to load LLVM on my bleeding edge Debian laptop tomorrow and see what happens there. I am pretty certain that this has nothing to do with the C++ library, and everything to do with the behaviour of mmap when the file that was mmaped is modified. I actually can reproduce this behaviour with the attached C test case. The program mmaps a file called 'data,' prints the last byte, truncates the file, then tries to read the last byte again. It causes a Bus Error on both the RedHat system and my Mac OS X workstation. Hen...

Evan Jones wrote: > I am pretty certain that this has nothing to do with the C++ library, > and everything to do with the behaviour of mmap when the file that was > mmaped is modified. I actually can reproduce this behaviour with the > attached C test case. The program mmaps a file called 'data,' prints the > last byte, truncates the file, then tries to read the last byte again. > It causes a Bus Error on both the RedHat system and my Mac OS X &...

Does NOUVEAU support mmaping a double-sized Framebuffer? When attempting to run, where fd refers to "/dev/fb0": mmap(ptr, screensize * 2, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); I get back an invalid argument error. This doesn't happen if I only request a single screensize. Is this a limitation of the driver? -------------- next part -------------- An HTML attachment was

Hi, I was wondering about the ARC and its interaction with the VM pagecache... When a file on a ZFS filesystem is mmaped, does the ARC cache get mapped to the process'' virtual memory? Or is there another copy? -Manoj

Hello, We're having a problem in Dovecot 1.1.8 with a failed assertion on certain mbox format mailboxes. It happens both with deliver when it attempts to delier to the mailbox, and with IMAP connections for the affected box (though I'm not sure what they're doing at the time). Mar 3 12:55:26 <snip> dovecot: Panic: IMAP(<snip>): file istream.c: line 81 (i_stream_read):

Attached another test program. I don't expect it to print any errors with any OS, but I'd like to confirm it for non-Linux SMP kernels. (Except for OpenBSD, it doesn't work correctly in it anyway because it doesn't support mixing write()s and mmap()) -------------- next part -------------- A non-text attachment was scrubbed... Name: concurrency.c Type: text/x-csrc Size: 2256

...i_stream_skip(input, part->physical_pos - input->v_offset); (gdb) print *ctx $1 = {pool = 0x0, key = 0x98f00 "MEETING", key_len = 7, charset = 0xa9788 "US-ASCII", unknown_charset = 0, search_header = 0} (gdb) print *input $2 = {v_offset = 1530, stream_errno = 0, mmaped = 0, closed = 0, seekable = 0, eof = 0, real_stream = 0xb9c78} (gdb) print *part $3 = {parent = 0xb2188, next = 0x0, children = 0xb2228, physical_pos = 1500, header_size = {physical_size = 857, virtual_size = 875, lines = 0}, body_size = {physical_size = 551367, virtual_size = 558548, lines...

...fa fa 0x1000214b0208: fa fa fa fa fa fa fa fa 0x1000214b0210: fa fa fa fa fa fa fa fa 0x1000214b0218: fa fa fa fa fa fa fa fa Stats: 0M malloced (0M for red zones) by 1 calls Stats: 0M realloced by 0 calls Stats: 0M freed by 0 calls Stats: 0M really freed by 0 calls Stats: 0M (128 full pages) mmaped in 1 calls mmaps by size class: 7:4095; mallocs by size class: 7:1; frees by size class: rfrees by size class: Stats: malloc large: 0 small slow: 1 ==393== ABORTING in build/projects/compiler-rt/lib/asan/lit_tests/Output/trncpy-overflow.cc.tmp.out ===============================...

<div dir='auto'>I am not familiar with that setting, but I have really struggled to find documentation on dealing with the framebuffer. Referring to this guide, "http://betteros.org/tut/graphics1.php#doublebuffer", I attempted to set the mmap allocation size to double, but it caused the mmap to fail. I no longer believe that it is a driver issue, though, because I just

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, I believe that I can pretty reliably reproduce the BUG mentioned in the attached dmesg output. (This doesn''t mean that you can, but I''ll detail what I''ve done here.) [This BUG is the same one that I reported last night.] 1) Create a 2 GB dynamically expanding disk. 2) Attach it to a VirtualBox machine. 3) Start the

...er prematurely return an ENOSPC, or lock up the operations trying to access the partition. I have bisected the problem to this commit: http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=commit;h=914ee295af418e936ec20a08c1663eaabe4cd07a (Btrfs: pwrite blocked when writing from the mmaped buffer of the same page) I am encountering the problem on a small-ish 3.5 GB Btrfs partition. I can replicate the problem with and without compression. I can also replicate the problem with and without reformating the partition. For most operations I run on this partition, Btrfs is performing w...

...Dtrace script ( attached ) which examines memory usage, using fbt:genunix:anon_resvmem:entry & return On my T2000 it totals the 65k pages being reserved by my application, printing out the total in bytes. Seems to work well, tested with a small app that malloced < 65 K, malloced 200M and mmapeed a 16M file and it appeared to get things correct. Could I just get a second pair of eyes to eyeball it. Basically I am looking at an app that seems to wander off the reservation in terms of memory usage, so wanted to rule out any bugs in the script. I have the app compiled in debug ( -g ) so...

...;> #1 0x7fff8bd827e0 (/usr/lib/system/libdyld.dylib+0x27e0) >> #2 0x0 >> Stats: 0M malloced (0M for red zones) by 3 calls >> Stats: 0M realloced by 0 calls >> Stats: 0M freed by 0 calls >> Stats: 0M really freed by 0 calls >> Stats: 1M (384 full pages) mmaped in 3 calls >> mmaps by size class: 7:4095; 8:2047; 9:1023; >> mallocs by size class: 7:1; 8:1; 9:1; >> frees by size class: >> rfrees by size class: >> Stats: malloc large: 0 small slow: 3 >> ==2738== ABORTING >> >> The failure of... &gt...

Hi all, ive been playing with squat indexes. Up to about 300.000 emails in a single mailbox this was working flawlessly. The search index file is about 500MB at that time. Ive now added some more emails, and at 450.000 or so emails im seeing a serious problem with squat index creation. It takes...f o r e v e r . The .tmp file is being so slowly, it will probably take 2-3 hours to create. Upto

...27e0 (/usr/lib/system/libdyld.dylib+0x27e0) >>> #2 0x0 >>> Stats: 0M malloced (0M for red zones) by 3 calls >>> Stats: 0M realloced by 0 calls >>> Stats: 0M freed by 0 calls >>> Stats: 0M really freed by 0 calls >>> Stats: 1M (384 full pages) mmaped in 3 calls >>> mmaps by size class: 7:4095; 8:2047; 9:1023; >>> mallocs by size class: 7:1; 8:1; 9:1; >>> frees by size class: >>> rfrees by size class: >>> Stats: malloc large: 0 small slow: 3 >>> ==2738== ABORTING >>> >&...

...ers/glider/src/gcc-asan/inst/lib/i386/libstdc++.6.dylib+0x3f8b) #1 0x91391724 (/usr/lib/system/libdyld.dylib+0x2724) #2 0x0 Stats: 0M malloced (0M for red zones) by 3 calls Stats: 0M realloced by 0 calls Stats: 0M freed by 0 calls Stats: 0M really freed by 0 calls Stats: 1M (256 full pages) mmaped in 2 calls mmaps by size class: 7:4095; 8:2047; mallocs by size class: 7:1; 8:2; frees by size class: rfrees by size class: Stats: malloc large: 0 small slow: 2 ==89768== ABORTING My guess is that this is caused by the following code being moved to a branch island: Dump of assembler...

...e mailbox bug). We're using mbox all around. Everything works smoothly but we still ocasionally get corrupt mailboxes and indexes that need to be wiped out. I setup 1.0-test45 on one of our mailservers to start testing it and ran into a few issues. The first one is if I try to use mail_read_mmaped=yes I get this error: Error: POP3(sobo1): file istream-raw-mbox.c: line 410 (istream_raw_mbox_get_body_size): assertion failed: (rstream->mail_size != (uoff_t)-1) for every mailbox. If I switch to mail_read_mmaped=no everything works, but performance is extremely bad. I have a few test mail...

...86/libstdc++.6.dylib+0x3f8b) > #1 0x91391724 (/usr/lib/system/libdyld.dylib+0x2724) > #2 0x0 > Stats: 0M malloced (0M for red zones) by 3 calls > Stats: 0M realloced by 0 calls > Stats: 0M freed by 0 calls > Stats: 0M really freed by 0 calls > Stats: 1M (256 full pages) mmaped in 2 calls > mmaps by size class: 7:4095; 8:2047; > mallocs by size class: 7:1; 8:2; > frees by size class: > rfrees by size class: > Stats: malloc large: 0 small slow: 2 > ==89768== ABORTING > > My guess is that this is caused by the following code being moved...

...gt; #1 0x91391724 (/usr/lib/system/libdyld.dylib+0x2724) > > #2 0x0 > > Stats: 0M malloced (0M for red zones) by 3 calls > > Stats: 0M realloced by 0 calls > > Stats: 0M freed by 0 calls > > Stats: 0M really freed by 0 calls > > Stats: 1M (256 full pages) mmaped in 2 calls > > mmaps by size class: 7:4095; 8:2047; > > mallocs by size class: 7:1; 8:2; > > frees by size class: > > rfrees by size class: > > Stats: malloc large: 0 small slow: 2 > > ==89768== ABORTING > > > > My guess is that this is...