Re: usp10/tests: [Resend] add tests for CR and LF chars and remove some trailing white space
Jeff Latimer l...@yless4u.com.au writes: The presence of numerics, linefeeds and carriage returns etc causes a new ScriptItem to be created. This patch tests that ScriptItems are created for LF and CR characters. It also tidies up the test strings and removes whitepace. It fails here: ../../../tools/runtest -q -P wine -M usp10.dll -T ../../.. -p usp10_test.exe.so usp10.c touch usp10.ok usp10.c:804: Test failed: Start pos [2] not = 11 (11) or end [3] pos not = 12 (14) usp10.c:807: Test failed: Start pos [3] not = 12 (14) or end [4] pos not = 13 (2076397231) usp10.c:810: Test failed: Start pos [4] not = 13 (2076397231) or end [5] pos not = 16 (0), cInChars = 14 usp10.c:834: Test failed: Start pos [2] not = 11 (11) or end [3] pos not = 14 (12), cInChars = 16 make[1]: *** [usp10.ok] Error 4 -- Alexandre Julliard julli...@winehq.org
Re: Minor dlls/comctl32/tests/listview.c simplification
On 4/21/2010 21:32, Gerald Pfeifer wrote:
ChangeLog:
Remove variable hwndheader which is not really used from test_items.
diff --git a/dlls/comctl32/tests/listview.c b/dlls/comctl32/tests/listview.c
index 2c5ef70..06f2ddd 100644
--- a/dlls/comctl32/tests/listview.c
+++ b/dlls/comctl32/tests/listview.c
@@ -1182,7 +1182,7 @@ static void test_items(void)
static void test_columns(void)
{
-HWND hwnd, hwndheader;
+HWND hwnd;
LVCOLUMN column;
DWORD rc;
INT order[2];
@@ -1207,7 +1207,6 @@ static void test_columns(void)
/* LVM_GETCOLUMNORDERARRAY */
hwnd = create_listview_control(LVS_REPORT);
-hwndheader = subclass_header(hwnd);
memset(column, 0, sizeof(column));
column.mask = LVCF_WIDTH;
Hi, Gerald.
You can't do this, subclassing is important thing here. And you will see
it if you run a test (that you should do before sending patch actually).
Re: imm32: Add tests for ImmAssociateContextEx (try 2)
André Hentschel n...@dawncrow.de writes: --- dlls/imm32/tests/imm32.c | 56 + 1 files changed, 51 insertions(+), 5 deletions(-) It fails here: ../../../tools/runtest -q -P wine -M imm32.dll -T ../../.. -p imm32_test.exe.so imm32.c touch imm32.ok imm32.c:350: Test succeeded inside todo block: ImmAssociateContextEx failed make[1]: *** [imm32.ok] Error 1 -- Alexandre Julliard julli...@winehq.org
Re: Intercept relay_call causes seh:raise_exception code=c0000005
Hi, All:
I also find out 2 special things
(1) The address of the array which causes the exception happens to be
the memory-mapped address of comctl32.dll (check the /proc/../smaps)
(2) If the address of the array is pointing to heap (from my malloc),
or some other places which are not occupied by any dll, then no
exception will occur
Originally I doubt the exception may be the bug of the RPC library I
am using (libc6-dev package inside Ubuntu).
However, if that's the case, my malloc pointer should also cause
exception (but it doesn't)
Still hope someone can give a hint on how to debug this question
Best wishes,
Jui-Hao
Message: 11
Date: Wed, 21 Apr 2010 09:37:53 -0400
From: Jui-Hao Chiang windtracek...@gmail.com
Subject: Intercept relay_call causes seh:raise_exception code=c005
To: wine-devel@winehq.org
Message-ID:
i2h52cf60ee1004210637gc7f20e5dq9b958127331b1...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Hi, All, I am currently using the WINEDEBUG=relay feature to intercept
function calls as the following
1. in dlls/ntdll/relay.c, insert code snippet in
static LONGLONG WINAPI relay_call( struct relay_descr *descr, unsigned
int idx, const INT_PTR *stack )
{
.
my_own_function(entry_point-name, nb_args stack); /* added by myself */
ret = call_entry_point( entry_point-orig_func, nb_args, stack + 1 );
/* original Wine code*/
}
LONGLONG
my_own_function(const char *funcname, int nb_args, const INT_PTR *stack)
{
/* CreateBitmap has 5 parameters, the 5th one is pointing to an array
while others are native type as the following
HBITMAP WINAPI CreateBitmap( INT width, INT height, UINT planes,
UINT bpp, LPCVOID bits )
*/
if (strcmp(funcname, CreateBitmap) == 0)
Rpc_CreateBitmap(*(stack+1), *(stack+2), *(stack+3),
*(stack+4), *(stack+5)); // this function just try to forward all
parameters to remote RPC server for record
}
2. Run program with WINEDEBUG=trace+all,relay wine notepad dump 21
3. If I only pass the parameter 1 to 4 to Rpc_CreateBitmap, then there
is no problem, but if I add the 5th one (which points to some array),
then the notepad aborts with he following debug message
0009:Call gdi32.CreateBitmap(0008,0008,0001,0001,7e95d822)
ret=7e8da083
0009:trace:seh:raise_exception code=c005 flags=0 addr=0xb754a21d
ip=b754a21d tid=0009
0009:trace:seh:raise_exception info[0]=0001
0009:trace:seh:raise_exception info[1]=7e95d822
0009:trace:seh:raise_exception eax=0055 ebx=b7593ff4 ecx=0033fa4c
edx=0001 esi=7e95d822 edi=0001
0009:trace:seh:raise_exception ebp=0033fa54 esp=0033fa44 cs=0073
ds=007b es=007b fs=0033 gs=003b flags=00010202
0009:trace:seh:call_vectored_handlers calling handler at 0x7b83fd50
code=c005 flags=0
0009:trace:seh:call_vectored_handlers handler at 0x7b83fd50 returned 0
0009:trace:seh:call_stack_handlers calling handler at 0x7bc4a480
code=c005 flags=0
0009:trace:seh:__regs_RtlUnwind code=c005 flags=2
0009:trace:seh:__regs_RtlUnwind calling handler at 0x7bc6bc50
code=c005 flags=2
0009:trace:seh:__regs_RtlUnwind handler at 0x7bc6bc50 returned 1
0009:exception in PE entry point
(proc=0x7e95a890,module=0x7e8c,reason=PROCESS_ATTACH,res=0x1)
4. But if I use malloc to copy the content of the array pointed by 5th
parameter, then there is no problem
LONGLONG
my_own_function(const char *funcname, int nb_args, const INT_PTR *stack)
{
char *buffer = NULL;
if (strcmp(funcname, CreateBitmap) == 0) {
buffer = (char*)malloc(.);
memcpy(buffer, *(stack+5), );
Rpc_CreateBitmap(*(stack+1), *(stack+2), *(stack+3),
*(stack+4), buffer); /* No exception if I do this */
}
Can anyone gives me a hint that what's happening here? or I am doing
some illegal operations?
Appreciate any comments,
Jui-Hao
Re: Intercept relay_call causes seh:raise_exception code=c0000005
Jui-Hao Chiang windtracek...@gmail.com writes: Hi, All: I also find out 2 special things (1) The address of the array which causes the exception happens to be the memory-mapped address of comctl32.dll (check the /proc/../smaps) (2) If the address of the array is pointing to heap (from my malloc), or some other places which are not occupied by any dll, then no exception will occur Originally I doubt the exception may be the bug of the RPC library I am using (libc6-dev package inside Ubuntu). However, if that's the case, my malloc pointer should also cause exception (but it doesn't) Still hope someone can give a hint on how to debug this question You are writing to a read-only array. -- Alexandre Julliard julli...@winehq.org
Re: Intercept relay_call causes seh:raise_exception code=c0000005
Alexandre Julliard julliard at winehq.org writes: Jui-Hao Chiang windtracekimo at gmail.com writes: Hi, All: I also find out 2 special things (1) The address of the array which causes the exception happens to be the memory-mapped address of comctl32.dll (check the /proc/../smaps) (2) If the address of the array is pointing to heap (from my malloc), or some other places which are not occupied by any dll, then no exception will occur Originally I doubt the exception may be the bug of the RPC library I am using (libc6-dev package inside Ubuntu). However, if that's the case, my malloc pointer should also cause exception (but it doesn't) Still hope someone can give a hint on how to debug this question You are writing to a read-only array. Yes, you are right, one of the RPC library function xdr_char() is doing the encoding on my input buffer *(stack+5), which is a read-only memory region for comctl32.dll. Originally I thought there is no problem with the RPC functions since the content, before and after encoding, remains the same from DPRINT. Thanks for your remind.
Re: DNS-sd Patch V.4
On Thu, 2010-04-22 at 11:56 -0600, C.W. Betts wrote: The Photoshop CS3 installer seems to stall during installation due to the lack of Bonjour (bug 15590). This patch attempts to fix it. No, it now succeeds in starting Bonjour, even if there's a native mdns server running (see comment #36). The problem is that when Bonjour finds that it can't do a wildcard bind it binds to specific addresses, thereby stealing traffic from the native server. We should investigate if the native server can be used by Photoshop. Then we could write a stub Bonjour service so that Photoshop will not attempt to install its own version. There's no need for a dns-sd wrapper dll in this scenario.
Re: DNS-sd Patch V.4
On Apr 22, 2010, at 1:09 PM, Hans Leidekker wrote: On Thu, 2010-04-22 at 11:56 -0600, C.W. Betts wrote: The Photoshop CS3 installer seems to stall during installation due to the lack of Bonjour (bug 15590). This patch attempts to fix it. No, it now succeeds in starting Bonjour, even if there's a native mdns server running (see comment #36). The problem is that when Bonjour finds that it can't do a wildcard bind it binds to specific addresses, thereby stealing traffic from the native server. My bad. Completely forgot about that. We should investigate if the native server can be used by Photoshop. Then we could write a stub Bonjour service so that Photoshop will not attempt to install its own version. One question about making a Windows service: would the programs still be making calls to the DLL? Or would the be making calls to the service? If they're making calls to the DLL, wouldn't something be needed to route those calls to the OS-native dns-sd implementation? Again, forgive my ignorance on this subject :/
