Displaying 9 results from an estimated 9 matches for "virtualqueri".
Did you mean:
virtualquery
2006 Oct 06
13
Need some help with latest win32-mmap
Hi all,
I''ve got the latest win32-mmap code checked into CVS. Unfortunately, it
seems that I''m not able to open an existing mapping and retrieve set
data. Below is a simple example that seems like it ought to work but
doesn''t. Any ideas?
# map1.rb
require ''win32/mmap''
include Win32
mmap = MMap.new(:name => ''alpha'', :size
2012 Jan 07
0
[LLVMdev] [llvm-commits] [PATCH][Compiler-rt] Windows implementation of mmap functionality in clear_cache_test and enable_execute_stack_test
Hi Ruben,
> I see I missed some curly braces. I also modified spacing a tiny bit.
Doesn't seem so. E.g. you have:
+ if ( !VirtualQuery(addr, &b, sizeof(b)) )
+ exit(1);
+ if( !VirtualProtect(b.BaseAddress, b.RegionSize,
PAGE_EXECUTE_READWRITE, &b.Protect) )
Add space after "if". Do not put spaces after "(" and before ")". Same
for other
2012 Jan 07
3
[LLVMdev] [PATCH][Compiler-rt] Windows implementation of mmap functionality in clear_cache_test and enable_execute_stack_test
Hi,
Attached is a patch for compiler-rt to allow it to compile with MinGW-w64
on Windows. Results aren't that bad.
x86 GCC and Clang do everything right, all tests pass.
x86_64 GCC fails a lot of tests. This is 99% sure a codegen issue.
38 - fixunssfti_test (Failed)
74 - fixunsdfti_test (Failed)
x86_64 Clang fails these tests:
2 - udivmodti4_test (SEGFAULT)
6 - fixdfti_test (Failed)
8 -
2012 Jan 07
1
[LLVMdev] [llvm-commits] [PATCH][Compiler-rt] Windows implementation of mmap functionality in clear_cache_test and enable_execute_stack_test
---------- Forwarded message ----------
From: Ruben Van Boxem <vanboxem.ruben at gmail.com>
Date: 2012/1/7
Subject: Re: [llvm-commits] [PATCH][Compiler-rt] Windows implementation of
mmap functionality in clear_cache_test and enable_execute_stack_test
To: Anton Korobeynikov <anton at korobeynikov.info>
2012/1/7 Anton Korobeynikov <anton at korobeynikov.info>
> Hello Ruben
2012 Jan 07
2
[LLVMdev] [llvm-commits] [PATCH][Compiler-rt] Windows implementation of mmap functionality in clear_cache_test and enable_execute_stack_test
2012/1/7 Anton Korobeynikov <anton at korobeynikov.info>
> Hi Ruben,
>
> > I see I missed some curly braces. I also modified spacing a tiny bit.
> Doesn't seem so. E.g. you have:
>
> + if ( !VirtualQuery(addr, &b, sizeof(b)) )
> + exit(1);
> + if( !VirtualProtect(b.BaseAddress, b.RegionSize,
> PAGE_EXECUTE_READWRITE, &b.Protect) )
>
2001 Dec 08
1
LoadOEMResource crash [Was: Re: Problem report: SHRINKER.ERR, fix to DEVICE_Open/CreateFileA? ]
Hi Pavel,
Right, my app also crashes in a different place under winedbg, although
it crashes in the same winedbg place under gdb.
I took a closer look at wine --winver nt40 --debugmsg +all.
I found something interesting. If I search for queue_exception, I find
that there is an exception raised before the LoadOEMCall, about
328klines in:
0806d398:Call
2013 Jun 25
0
[LLVMdev] [PATCH] Windows implementation of enable_execute_stack
2013/5/30 Ruben Van Boxem <vanboxem.ruben at gmail.com>
> 2013/5/25 Aaron Ballman <aaron at aaronballman.com>
>
>> On Fri, May 24, 2013 at 5:53 PM, Ruben Van Boxem
>> <vanboxem.ruben at gmail.com> wrote:
>> > Hi,
>> >
>> > I submitted this patch a long while ago, together with a bunch of other
>> > changes (some of which got
2005 May 05
2
LockWindowUpdate
Hi,
I've got a program that produces these error messages when started with wine.
fixme:dc:LockWindowUpdate (0x10024), partial stub!
fixme:dc:LockWindowUpdate ((nil)), partial stub!
fixme:dc:LockWindowUpdate (0x10024), partial stub!
fixme:dc:LockWindowUpdate ((nil)), partial stub!
fixme:dc:LockWindowUpdate (0x10024), partial stub!
fixme:dc:LockWindowUpdate ((nil)), partial stub!
The program
2001 Dec 11
0
VirtualProtect and app crash: what's your interpretation?
Here is my thought process on why the application crashes with a
protection violation reading a section of memory.
I used IDA to disassemble the app. Here's the section where it reads
from memory and crashes because of a protection violation:
00760D4A sub_760D4A proc near ; CODE XREF:
sub_75FCB0+159^Xp
00760D4A push ebp
00760D4B mov