search for: mmapeed

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

On Nov 22, 2005, at 17:18, Reid Spencer wrote: > Your patch uses an operating system call that is not portable. All > non-portable code needs to be located in the lib/System library. Yep! I know. That is why I posted it for discussion. I'm not sure if this is the "right" way to fix the problem, or if there is a different fix that should be applied (like perhaps copying the

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

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

Hi, Two cores over the weekend, same assert message in syslog: imap(user): file message-body-search.c: line 393 (message_body_search_ctx): assertion failed: (input->v_offset <= part->physical_pos) Setup: Solaris 9, imap usage only, mbox format, dovecot compiled with gcc 4.0.1. gdb sessions of the two core files attached. Let me know if you need further analysis of the cores.

On Fri, Nov 02, 2012 at 06:45:07PM +0400, Alexey Samsonov wrote: > Hi, Jack! > > > I'll take a look at this. However, tests below fail for a different reason > (they don't use Debug/AsanTest at all). > How do you configure a CMake build tree? Can you somehow get (or run > manually) the script which is used > for running log-path_test.cc and other failing test

<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

I''m encountering premature ENOSPC issues recently where my Btrfs testing partition will either 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

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

Jack, can you please upload this test somewhere? On Thu, Nov 29, 2012 at 10:09 AM, Kostya Serebryany <kcc at google.com> wrote: > +glider > The compiler hardly matters here, I would expect the same failures with > clang. > Alex, could you please take a look? > > --kcc > > > On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <howarth at bromo.med.uc.edu> >

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

I debugged this a bit and it seems the mach_override patching of __cxa_throw is bogus. The start of that function is patched to jump to garbage. Breakpoint 1, 0x0000000100001c19 in main () (gdb) display/i $pc 2: x/i $pc 0x100001c19 <main+318>: callq 0x100016386 <dyld_stub___cxa_throw> (gdb) si 0x0000000100016386 in dyld_stub___cxa_throw () 2: x/i $pc 0x100016386

Looks like this happens on x86_64 because the position of __cxa_throw is too far from the allocated branch island (should be <2G). This can be solved by allocating the branch islands somewhere near the text segment (look for kIslandEnd in asan_mac.cc, this is currently 0x7fffffdf0000) or by patching the function with a longer instruction sequence that stores the jump target in a register and

We're currently on dovecot 0.99.10 with a few modifications (including one very nasty hack for the blank line at the beginning of the 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

Just want to remind everyone that we plan to stop using mach_override in asanin favor of OSX's native function interposition. So, we probably don't want to spend too much effort fixing mach_override. --kcc On Fri, Nov 30, 2012 at 4:46 AM, Alexander Potapenko <glider at google.com>wrote: > Looks like this happens on x86_64 because the position of __cxa_throw > is too far from

On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > Just want to remind everyone that we plan to stop using mach_override in > asanin favor of OSX's native function interposition. > So, we probably don't want to spend too much effort fixing mach_override. > > --kcc Kostya, Is the native function interposition that is being adopted based on...