Re: disabling FORTIFY_SOURCE
On Sat, Oct 23, 2010 at 11:54:27PM +, Dan Kegel wrote: Hi Kees, sure, supporting Fortify in Wine would be great, but it's not clear how long it will take to fix Wine so it works with Fortify. Which would you prefer: 1) have Wine broken for an unknown and possibly long time or 2) have Wine working, but without Fortify, until the bugs are fixed ? Actually I would like to know if its just more than the dlls/shell32/pidl.c problem... (And of course also the stupid warn_unused_results warning spam, which we disabled already.) Ciao, Marcus
Re: disabling FORTIFY_SOURCE
Marcus Meissner mar...@jet.franken.de wrote: Actually I would like to know if its just more than the dlls/shell32/pidl.c problem... It's the problem with any storage declared as something[1], there are plenty of them in win32, and that's perfectly valid code. (And of course also the stupid warn_unused_results warning spam, which we disabled already.) It's also infamous longjmp causes uninitialized stack frame: http://bugs.winehq.org/show_bug.cgi?id=21405 -- Dmitry.
Re: disabling FORTIFY_SOURCE
On Sun, Oct 24, 2010 at 03:44:35PM +0900, Dmitry Timoshkov wrote: Marcus Meissner mar...@jet.franken.de wrote: Actually I would like to know if its just more than the dlls/shell32/pidl.c problem... It's the problem with any storage declared as something[1], there are plenty of them in win32, and that's perfectly valid code. Actually FORTIFY knows those constructs in standalone structs and handles them correctly. It is only if they are embedded within another struct or unions when it has problems. Ciao, Marcus
Re: ddraw: Add tests for the foreground window set by SetCooperativeLevel
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6448 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout
missing tests in test.winehq.org
Hello, looking at http://test.winehq.org, i remarked that the file ddraw/tests/ddrawmodes does not exist and so it is never tested. Does anyone have an explanation for this fact? A+ David
Re: new
Yes I've tried that a good while ago without result. So I wonder how to proceed now. Thanks --- On Sat, 10/23/10, Ricardo Filipe ricardojdfil...@gmail.com wrote: From: Ricardo Filipe ricardojdfil...@gmail.com Subject: Re: new To: Michael Sgier scrat_is_h...@yahoo.com Cc: wine-devel@winehq.org Date: Saturday, October 23, 2010, 10:14 PM 2010/10/23 Michael Sgier scrat_is_h...@yahoo.com HiI'm new to this but know that MS Flight Simulator would one need little tweak to run flight school etc. (already worked once) So I've downloaded git and would be thankful for hints on how to proceed and find those bugs in FS9. I also would prefer using Eclipse/Linux, but anyway thanks for help.Many thanksMichael hi michael! if it has already worked before you need to do some regression testing to see when the new error was introduced. http://wiki.winehq.org/RegressionTesting as far as using eclipse or whatever that's your choice. use what you feel confortable with to compile and test code. have fun :)
Re: disabling FORTIFY_SOURCE
Kees Cook k...@ubuntu.com writes: It seems to me that disabling FORTIFY_SOURCE is a mistake. It offers a great many protections, and virtually every distribution has very intentionally turned on this compiler flag by default. Given Wine's size[1], I would argue the benefits[2] outweigh the hassle of rearranging the structures and accessors to not trick the compiler into allocating memory beyond the end of the structure for incoming strings. It has found, at least in other projects, a lot of potential problems, and better yet, has repeatedly turned exploitable vulnerabilities into simple denial of services. So far in Wine, all it has done is repeatedly turn perfectly valid code into denial of service. Actually, even if Fortify worked correctly, the benefits would most likely be small, given that we make little use of the standard libc functions. Though given the trouble we've had so far, I shudder to think what would happen if we used libc functions all over the place. Fortify is a nice idea in theory, and I'd certainly encourage developers to enable it to see if it catches anything useful. But at this point it's not reliable enough to be forced upon end users. -- Alexandre Julliard julli...@winehq.org
Re: missing tests in test.winehq.org
On 10/24/2010 09:23 AM, paulo lesgaz wrote: Hello, looking at http://test.winehq.org, i remarked that the file ddraw/tests/ddrawmodes does not exist and so it is never tested. What about: http://test.winehq.org/data/tests/ddraw:ddrawmodes.html or am I missing something? -- Cheers, Paul.
Test for window messages of a property sheet with custom dialog proc (bug 12104)
Hello,
the attached patch consists of a test case for following bug:
http://bugs.winehq.org/show_bug.cgi?id=12104
This test shows how cygwin's setup checks if a WM_SIZE message
was received (by the custom window proc).
In wine only the property page gets such a message - not the sheet.
If I got it right, tests which would fail in wine are prefixed with todo_wine?
I want to ask if this patch looks right for inclusion and if the
location (dlls/comctl32/tests/) is right?
Kind regards,
Bernhard
From e89af2359528a559deec7cc35cbc017ab977f079 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= bernha...@vr-web.de
Date: Sun, 24 Oct 2010 13:17:01 +0200
Subject: Test for window messages of a property sheet with custom dialog proc.
(As seen in bug 12104 - Cygwin's setup.exe doesn't resize properly)
---
dlls/comctl32/tests/propsheet.c | 122 +++
dlls/comctl32/tests/resources.h |1 +
dlls/comctl32/tests/rsrc.rc |7 ++
3 files changed, 130 insertions(+), 0 deletions(-)
diff --git a/dlls/comctl32/tests/propsheet.c b/dlls/comctl32/tests/propsheet.c
index bfbaaa0..6232442 100644
--- a/dlls/comctl32/tests/propsheet.c
+++ b/dlls/comctl32/tests/propsheet.c
@@ -525,6 +525,127 @@ static void test_custom_default_button(void)
DestroyWindow(hdlg);
}
+static WNDPROC oldWndProc;
+static BOOL clientRectValid;
+struct message_entry {
+UINT msg;
+CHAR source[10];
+};
+static const struct message_entry message_array[] = {
+{ PSCB_PRECREATE, sheet_cb },
+{ PSCB_INITIALIZED, sheet_cb },
+{ WM_WINDOWPOSCHANGING, sheet_wp },
+{ WM_NCCALCSIZE,sheet_wp },
+{ WM_WINDOWPOSCHANGED, sheet_wp },
+{ WM_MOVE, sheet_wp },
+{ WM_SIZE, sheet_wp }
+};
+
+static void check_message(HWND hwnd, UINT msg, PCHAR source)
+{
+static UINT msg_count;
+
+/*trace(check_message: msg[0x%08x] received by %s\n, msg, source);*/
+
+if (msg_count sizeof(message_array)/sizeof(message_array[0]))
+{
+/* disabled because todo_wine would fail because some messages arrive correct in wine
+ok(message_array[msg_count].msg == msg,
+received message 0x%x when expecting 0x%x\n,
+msg, message_array[msg_count].msg);
+ok(strcmp(message_array[msg_count].source, source) == 0,
+receiver is %s when expecting %s\n,
+source, message_array[msg_count].source);
+*/
+
+msg_count++;
+}
+}
+
+static LRESULT CALLBACK sheet_callback_messages_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
+{
+check_message(hwnd, msg, sheet_wp);
+
+switch (msg)
+{
+case WM_SIZE:
+/*trace(sheet_callback_messages_proc: clientRectValid[%d]\n, clientRectValid);*/
+clientRectValid = TRUE;
+break;
+case WM_CTLCOLORSTATIC:
+keybd_event(VK_ESCAPE, 0, 0, 0);
+break;
+}
+
+return CallWindowProc (oldWndProc, hwnd, msg, wParam, lParam);
+}
+
+static int CALLBACK sheet_callback_messages(HWND hwnd, UINT msg, LPARAM lparam)
+{
+check_message(hwnd, msg, sheet_cb);
+
+switch (msg)
+{
+case PSCB_INITIALIZED:
+oldWndProc = (WNDPROC)GetWindowLongPtr (hwnd, GWLP_WNDPROC);
+SetWindowLongPtr (hwnd, GWLP_WNDPROC, (LONG_PTR)sheet_callback_messages_proc);
+return TRUE;
+}
+
+return TRUE;
+}
+
+static INT_PTR CALLBACK page_dlg_proc_messages(HWND hwnd, UINT msg, WPARAM wparam,
+ LPARAM lparam)
+{
+check_message(hwnd, msg, page);
+
+return FALSE;
+}
+
+static void test_messages(void)
+{
+HPROPSHEETPAGE hpsp[1];
+PROPSHEETPAGEA psp;
+PROPSHEETHEADERA psh;
+HWND hdlg;
+
+memset(psp, 0, sizeof(psp));
+psp.dwSize = sizeof(psp);
+psp.dwFlags = 0;
+psp.hInstance = GetModuleHandleA(NULL);
+U(psp).pszTemplate = MAKEINTRESOURCE(IDD_PROP_PAGE_MESSAGE_TEST);
+U2(psp).pszIcon = NULL;
+psp.pfnDlgProc = page_dlg_proc_messages;
+psp.lParam = 0;
+
+hpsp[0] = CreatePropertySheetPageA(psp);
+
+memset(psh, 0, sizeof(psh));
+psh.dwSize = sizeof(psh);
+psh.dwFlags = PSH_NOAPPLYNOW | PSH_WIZARD | PSH_USECALLBACK
+ /*| PSH_MODELESS */ | PSH_USEICONID;
+psh.pszCaption = test caption;
+psh.nPages = 1;
+psh.hwndParent = GetDesktopWindow();
+U3(psh).phpage = hpsp;
+psh.pfnCallback = sheet_callback_messages;
+
+hdlg = (HWND)PropertySheetA(psh);
+if (hdlg == INVALID_HANDLE_VALUE)
+{
+win_skip(comctl32 4.70 needs dwSize adjustment\n);
+psh.dwSize = sizeof(psh) - sizeof(HBITMAP) - sizeof(HPALETTE) - sizeof(HBITMAP);
+hdlg = (HWND)PropertySheetA(psh);
+}
+ShowWindow(hdlg,SW_NORMAL);
+
+todo_wine
+ok(clientRectValid, The required WM_SIZE was never sent to the sheet.\n);
+
+DestroyWindow(hdlg);
+}
+
START_TEST(propsheet)
{
test_title();
@@ -533,4 +654,5 @@
Re : missing tests in test.winehq.org
but nothing at http://test.winehq.org/data/8c5718ec9d0613be7208e1ceaecac0e7434c4cf5/index_2003.html for instance. A+ David De : Paul Vriens paul.vriens.w...@gmail.com À : paulo lesgaz jeremielapu...@yahoo.fr Cc : wine-devel@winehq.org Envoyé le : Dim 24 octobre 2010, 11h 43min 24s Objet : Re: missing tests in test.winehq.org On 10/24/2010 09:23 AM, paulo lesgaz wrote: Hello, looking at http://test.winehq.org, i remarked that the file ddraw/tests/ddrawmodes does not exist and so it is never tested. What about: http://test.winehq.org/data/tests/ddraw:ddrawmodes.html or am I missing something? -- Cheers, Paul.
Re: Re : missing tests in test.winehq.org
Am 24.10.2010 13:51, schrieb paulo lesgaz: but nothing at http://test.winehq.org/data/8c5718ec9d0613be7208e1ceaecac0e7434c4cf5/index_2003.html for instance. A+ David *De :* Paul Vriens paul.vriens.w...@gmail.com *À :* paulo lesgaz jeremielapu...@yahoo.fr *Cc :* wine-devel@winehq.org *Envoyé le :* Dim 24 octobre 2010, 11h 43min 24s *Objet :* Re: missing tests in test.winehq.org On 10/24/2010 09:23 AM, paulo lesgaz wrote: Hello, looking at http://test.winehq.org, i remarked that the file ddraw/tests/ddrawmodes does not exist and so it is never tested. What about: http://test.winehq.org/data/tests/ddraw:ddrawmodes.html or am I missing something? -- Cheers, Paul. When one OS type has nothing to report for a test, then it is not listed. -- Best Regards, André Hentschel
Re: Re : missing tests in test.winehq.org
On 10/24/2010 01:51 PM, paulo lesgaz wrote: but nothing at http://test.winehq.org/data/8c5718ec9d0613be7208e1ceaecac0e7434c4cf5/index_2003.html for instance. (And to list, I should remember to hit the correct button). That's because there are no failures/skips for ddraw:drawmodes on that platform. What did you expect to see? -- Cheers, Paul.
Re: disabling FORTIFY_SOURCE
On 10/24/2010 12:32 AM, Marcus Meissner wrote:
Actually I would like to know if its just more than the dlls/shell32/pidl.c
problem...
If you take a look at winternl.h you'll see number of structures there look
like:
typedef struct _foo {
ULONG length;
WCHAR buffer[1];
} foo, *pfoo;
Or just grep for '\[1\]' in include directory. Lots and lots of declarations
in all different places.
Vitaliy.
Re: Test for window messages of a property sheet with custom dialog proc (bug 12104)
On 10/24/2010 05:20 AM, Bernhard Übelacker wrote: If I got it right, tests which would fail in wine are prefixed with todo_wine? I want to ask if this patch looks right for inclusion and if the location (dlls/comctl32/tests/) is right? +/* disabled because todo_wine would fail because some messages arrive correct in wine No, it doesn't look right. If you testing for missing messages, then you should test all messages as done in some other places. See dlls/comctl32/tests/msg.h and where it's used. Vitaliy.
Re: disabling FORTIFY_SOURCE
On Sun, Oct 24, 2010 at 09:50:42AM -0600, Vitaliy Margolen wrote:
On 10/24/2010 12:32 AM, Marcus Meissner wrote:
Actually I would like to know if its just more than the dlls/shell32/pidl.c
problem...
If you take a look at winternl.h you'll see number of structures
there look like:
typedef struct _foo {
ULONG length;
WCHAR buffer[1];
} foo, *pfoo;
Or just grep for '\[1\]' in include directory. Lots and lots of
declarations in all different places.
As I already wrote, this works.
Here is a sample code which shows the problem dlls/shell32/pidl.c has:
$ cat xx1.c
#include string.h
#include stdlib.h
struct foo {
int x;
char y[1];
};
union bar {
struct foo fo;
long y;
float fl;
};
struct berk {
int t;
union bar b;
};
int
main(int argc, char **argv) {
struct berk *x1;
struct foo *x2;
x1 = malloc (sizeof(struct berk) + 5);
x2 = malloc (sizeof(struct foo) + 5);
strcpy(x1-b.fo.y, hallo);
strcpy(x2-y, hallo);
}
$ gcc -O2 -Wall -D_FORTIFY_SOURCE=2 -g xx1.c -o xx1
xx1.c: In function ‘main’:
xx1.c:28:1: warning: control reaches end of non-void function
In file included from /usr/include/string.h:640:0,
from xx1.c:1:
In function ‘strcpy’,
inlined from ‘main’ at xx1.c:26:8:
/usr/include/bits/string3.h:107:3: warning: call to
__builtin___strcpy_chk will always overflow destination buffer
Only the strcpy(x1-b.fo.y, hallo); with the nested struct is warned
about, while the second strcpy works fine.
It is just nested structs it does not like at this time.
Ciao, Marcus
Re: disabling FORTIFY_SOURCE
On 10/24/10 8:50 AM, Vitaliy Margolen wrote: On 10/24/2010 12:32 AM, Marcus Meissner wrote: Actually I would like to know if its just more than the dlls/shell32/pidl.c problem... Or just grep for '\[1\]' in include directory. Lots and lots of declarations in all different places. Stoopid question time. Is there a better method of declaring these than making them 2 char arrays? Can we 'assume' a maximum length and set them to that to prevent possible buffer overflows or is this something that we have to accept and work with? I understand that we want to keep the memory footprint for Wine as low as possible but we also don't want to introduce possible exploits in the process. James McKenzie
Re: [2/4] ddraw/tests: test some more caps combinations
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6459 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found
Re: [3/4] ddraw: fix DDSCAPS_3DDEVICE surfaces always setting DDSCAPS_VISIBLE
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6460 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found
Re: [PATCH 2/3] [Msvcrt]: put in place the full scheme for paramter validation (the _s family of functions)
Hi, Only debugging version of the dll is passing data to invalid_paramter_handler. I guess it's why we shouldn't do it. There already is a test for it in msvcr90 (see strtoi64 tests). Because it was not strict enough it will not show it very well. Currently it will not show that it was expecting invalid_parameter_handler to be invoked (but will fail checking errno that should not be changed). Of course this behavior may vary between msvcrXX dlls, I have tested it only with msvcr90 and msvcrt on Windows XP. Cheers, Piotr
