Re: Working on "DOS" VGA.
On 4/3/2010 11:34 AM, Alexandre Julliard wrote: > Stefan Dösinger writes: > > >> Am 02.04.2010 um 02:08 schrieb chris ahrendt: >> >> >>> Just my 2 phennings worth on this... >>> Why reinvent the wheel... I would say instead of doing the emulator inside >>> wine... or a JIT... why not have >>> wine intersept the call to start the vm86 mode.. and forks off and starts >>> DOSEMU or whatever DOS box system is >>> configured.. That way wine doesnt have to worry about it... >>> >> Because you can mix modes in one executable. Take for example the >> average modern dos game: They start as real mode apps, then switch to >> a 32 bit protected mode dos extender(e.g. dos4gw.exe). I wouldn't be >> surprised if the app can transform itself into a Win16 app that tries >> to pop up a window. Wouldn't work well in Linux dosemu. >> > DOS apps can't do that. Pretty much the only thing you really have to > share is the filesystem, and it should be easy to configure DosBox to > mount ~/.wine/drive_c, and to invoke Wine when a DOS app starts a > Windows binary. > > There's no reason to replicate DosBox inside Wine. On the contrary, a > nice project would be to improve integration with an external DOS > emulator and then rip out the half-broken vm86 support from Wine. > > That is what I would think should be done... chris
Re: Working on "DOS" VGA.
Just my 2 phennings worth on this... Why reinvent the wheel... I would say instead of doing the emulator inside wine... or a JIT... why not have wine intersept the call to start the vm86 mode.. and forks off and starts DOSEMU or whatever DOS box system is configured.. That way wine doesnt have to worry about it... chris
Latest Git Fails tools/install
> Compiling Wine. Grab a lunch or two, rent a video, or whatever, > in the meantime... > > config.status: executing Makefile commands > cat: Make.tmp: No such file or directory > config.status: error: could not create Makefile > make: *** [Makefile] Error 1 > config.status: executing Makefile commands > cat: Make.tmp: No such file or directory > config.status: error: could not create Makefile > make: *** [Makefile] Error 1 > > Compilation failed, aborting install. Ideas? Chris
Make issue with latest git
Just did the latest git and got the following : all -c wineapploader /usr/local/bin/`dirname programs/msiexec/__installprog__` /usr/bin/install: cannot create regular file `/usr/local/bin/programs/msiexec': No such file or directory make[1]: *** [programs/msiexec/__installprog__] Error 1 make[1]: Leaving directory `/work/wine-git/programs' make: *** [programs/__install__] Error 2 if I went into the /usr/local/bin there is no programs directory so made the directory and reran make install or tools/install and worked fine... Did not need this until todays git as yesterdays worked just fine without the directory... chris
CPP Check Runs Clean but found these Style Issues on Latest Git...
Don't know if anyone is interested in this or not but I thought I would send this out to the list. CPPCheck is now running clean on the GIT tree... but its showing some style issues. If they are there for API compatibility let me know and I will ignore them from now on. Here they are: FileLineStyle Problem dlls/dnsapi/ns_name.c 1 The function dns_ns_name_skip' is never used The function dns_ns_name_uncompress' is never used dlls/gdi32/enhmfdrv/mapping.c 1 The function EMFDRV_ModifyWorldTransform' is never used The function EMFDRV_OffsetViewportOrg' is never used The function EMFDRV_OffsetWindowOrg' is never used The function EMFDRV_ScaleViewportExt' is never used The function EMFDRV_ScaleWindowExt' is never used The function EMFDRV_SetMapMode' is never used The function EMFDRV_SetViewportExt' is never used The function EMFDRV_SetViewportOrg' is never used The function EMFDRV_SetWindowExt' is never used The function EMFDRV_SetWindowOrg' is never used The function EMFDRV_SetWorldTransform' is never used dlls/gdi32/mfdrv/dc.c 1 The function MFDRV_AbortPath' is never used The function MFDRV_BeginPath' is never used The function MFDRV_CloseFigure' is never used The function MFDRV_EndPath' is never used The function MFDRV_ExcludeClipRect' is never used The function MFDRV_FillPath' is never used The function MFDRV_FlattenPath' is never used The function MFDRV_IntersectClipRect' is never used The function MFDRV_OffsetClipRgn' is never used The function MFDRV_RestoreDC' is never used The function MFDRV_SaveDC' is never used The function MFDRV_SelectClipPath' is never used The function MFDRV_SetBkMode' is never used The function MFDRV_SetMapperFlags' is never used The function MFDRV_SetPolyFillMode' is never used The function MFDRV_SetRelAbs' is never used The function MFDRV_SetROP2' is never used The function MFDRV_SetStretchBltMode' is never used The function MFDRV_SetTextAlign' is never used The function MFDRV_SetTextCharacterExtra' is never used The function MFDRV_SetTextJustification' is never used The function MFDRV_StrokeAndFillPath' is never used The function MFDRV_StrokePath' is never used The function MFDRV_WidenPath' is never used dlls/rpcrt4/rpc_transport.c 1 The function RpcNetworkIsProtseqValidA' is never used dlls/rpcrt4/rpc_transport.c 700 The scope of the variable b_handle can be reduced dlls/wininet/cookie.c 1 The function IsDomainLegalCookieDomainW' is never used dlls/wininet/cookie.c 225 The scope of the variable len can be reduced dlls/wininet/dialogs.c 132 The scope of the variable q can be reduced dlls/wininet/dialogs.c 181 The scope of the variable u_len can be reduced dlls/wininet/ftp.c 359 The scope of the variable nResCode can be reduced dlls/wininet/ftp.c 1261The scope of the variable retval can be reduced dlls/wininet/http.c 1 The function IsHostInProxyBypassList' is never used dlls/wininet/http.c 750 The scope of the variable userlen can be reduced dlls/wininet/http.c 751 The scope of the variable passlen can be reduced dlls/wininet/http.c 3355The scope of the variable lpszCookies can be reduced dlls/wininet/http.c 3365The scope of the variable cnt can be reduced dlls/wininet/http.c 3868The scope of the variable headerlen can be reduced dlls/wininet/internet.c 1 The function DllMain' is never used dlls/wininet/in
Re: CPPCheck Dec 29
On 12/29/2009 11:17 PM, Alasdair Sinclair wrote: > >return size; ok will file a false positive... thanks chris
CPPCheck Dec 29
I just ran CPP check this evening and got the following :
rpcrt4/rpc_transport.c 490 (error) Uninitialized variable smb_floor
761 (error) Uninitialized variable pipe_floor
885 (error) Uninitialized variable tcp_floor
If you look at the code :
static size_t rpcrt4_ncacn_np_get_top_of_tower(unsigned char *tower_data,
const char *networkaddr,
const char *endpoint)
{
twr_empty_floor_t *smb_floor;
twr_empty_floor_t *nb_floor;
size_t size;
size_t networkaddr_size;
size_t endpoint_size;
TRACE("(%p, %s, %s)\n", tower_data, networkaddr, endpoint);
networkaddr_size = networkaddr ? strlen(networkaddr) + 1 : 1;
endpoint_size = endpoint ? strlen(endpoint) + 1 : 1;
size = sizeof(*smb_floor) + endpoint_size + sizeof(*nb_floor) +
networkaddr_size;
if (!tower_data)
return size;
It is correct in that these three are not initialised and could point to
anything on the local stack.
Additionally if you look above you can get potentially a bogus return..
Additionally for tcp_floor:
static size_t rpcrt4_ip_tcp_get_top_of_tower(unsigned char *tower_data,
const char *networkaddr,
unsigned char tcp_protid,
const char *endpoint)
{
twr_tcp_floor_t *tcp_floor;
twr_ipv4_floor_t *ipv4_floor;
struct addrinfo *ai;
struct addrinfo hints;
int ret;
size_t size = sizeof(*tcp_floor) + sizeof(*ipv4_floor);
TRACE("(%p, %s, %s)\n", tower_data, networkaddr, endpoint);
if (!tower_data)
return size;
Same problem here as well
Chris
strangeness under Dec 14th Wine Git
Just a little nit I noticed with yesterdays Git tree... When you give a window other than the wine window the focus... the wine window does not go into the background... so IF I have 2 or 3 windows open with a wine app running and click on say thunderbird... or firefox to look something up I have to move the wine window to the bottom of the screen. It looses focus (turns grey) but does not go to the background... Chris
Re: RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff
Roderick Colenbrander wrote: > On Wed, Nov 25, 2009 at 3:46 AM, chris ahrendt wrote: >> Roderick Colenbrander wrote: >>> On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt wrote: >>>> Ok going through and looking at the next failure in wine tests I found >>>> this one : >>>> >>>> >>>> If you look at the code its: >>>> >>>> >>>> 779 color = getPixelColor(device, 160, 120); >>>> 780 red = (color & 0x00ff) >> 16; >>>> 781 green = (color & 0xff00) >> 8; >>>> 782 blue = (color & 0x00ff); >>>> 783 ok(red == 0x00 && green == 0x00 && blue >= 0xfe && blue <= 0xff , >>>> 784"DSTALPHA on frame buffer returned color 0x%08x, expected >>>> 0x00ff\n", color); >>>> >>>> >>>> but in MSDN it says : >>>> >>>> This value is a 32-bit value used to specify an RGB color or CLR_INVALID >>>> >>>> Format of the rgb color is : >>>> >>>> 0x00bbggrr >>>> >>>> The low-order byte contains a value for the relative intensity of red, the >>>> second byte contains a value for green, and >>>> the third byte contains a value for blue. >>>> >>>> The high-order byte must be zero. >>>> >>>> The maximum value for a single byte is 0xFF. >>>> >>>> so shouldn't it be something like this: >>>> >>>>red = color & 0x00FF; >>>>green = ( color & 0xFF00 ) >> 8; >>>>blue = ( color & 0x00FF ) >> 16; >>>> >>>> not the what is in the test? because of the following C action >>>> >>>> expression1 >> shift_value >>>> >>>> Returns expression1 with its bits shifted to the right by the shift_value. >>>> The leftmost bits are replaced with zeros if >>>> the value is nonnegative or unsigned. This result is the integer part of >>>> expression1 divided by 2 raised to the power of >>>> shift_value. If expression1 is signed, then the result is implementation >>>> specific. >>>> >>>> so the test seems to be assigning the wrong values to the RGB Correct? >>>> >>>> chris >>>> >>> We are creating the framebuffer in the ARGB format (see init_d3d9). >>> D3D supports a variety of formats and we don't use the gdi RGB macro. >>> >>> Roderick >>> >>> >> Ok... but apparently this is returning it though in the above bbggrr format >> when color comes back so how do you set it >> to come back in the ARGB format??? Is that setup in the init_d3d9? >> >> chris >> > > The test passes properly on Wine + Nivida and I believe even on Intel. > There are just some bugs in the ATI drivers. That's the case with most > of the failing ddraw/d3d tests on ATI and other drivers. > > Roderick > > Oh I realise that... thats why I am trying to figure out where so I can open a bug with ATI... chris
Re: RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff
Roderick Colenbrander wrote: > On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt wrote: >> Ok going through and looking at the next failure in wine tests I found this >> one : >> >> >> If you look at the code its: >> >> >> 779 color = getPixelColor(device, 160, 120); >> 780 red = (color & 0x00ff) >> 16; >> 781 green = (color & 0xff00) >> 8; >> 782 blue = (color & 0x00ff); >> 783 ok(red == 0x00 && green == 0x00 && blue >= 0xfe && blue <= 0xff , >> 784"DSTALPHA on frame buffer returned color 0x%08x, expected >> 0x00ff\n", color); >> >> >> but in MSDN it says : >> >> This value is a 32-bit value used to specify an RGB color or CLR_INVALID >> >> Format of the rgb color is : >> >> 0x00bbggrr >> >> The low-order byte contains a value for the relative intensity of red, the >> second byte contains a value for green, and >> the third byte contains a value for blue. >> >> The high-order byte must be zero. >> >> The maximum value for a single byte is 0xFF. >> >> so shouldn't it be something like this: >> >>red = color & 0x00FF; >>green = ( color & 0xFF00 ) >> 8; >>blue = ( color & 0x00FF ) >> 16; >> >> not the what is in the test? because of the following C action >> >> expression1 >> shift_value >> >> Returns expression1 with its bits shifted to the right by the shift_value. >> The leftmost bits are replaced with zeros if >> the value is nonnegative or unsigned. This result is the integer part of >> expression1 divided by 2 raised to the power of >> shift_value. If expression1 is signed, then the result is implementation >> specific. >> >> so the test seems to be assigning the wrong values to the RGB Correct? >> >> chris >> > We are creating the framebuffer in the ARGB format (see init_d3d9). > D3D supports a variety of formats and we don't use the gdi RGB macro. > > Roderick > > Ok... but apparently this is returning it though in the above bbggrr format when color comes back so how do you set it to come back in the ARGB format??? Is that setup in the init_d3d9? chris
RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff
Ok going through and looking at the next failure in wine tests I found this one : If you look at the code its: 779 color = getPixelColor(device, 160, 120); 780 red = (color & 0x00ff) >> 16; 781 green = (color & 0xff00) >> 8; 782 blue = (color & 0x00ff); 783 ok(red == 0x00 && green == 0x00 && blue >= 0xfe && blue <= 0xff , 784"DSTALPHA on frame buffer returned color 0x%08x, expected 0x00ff\n", color); but in MSDN it says : This value is a 32-bit value used to specify an RGB color or CLR_INVALID Format of the rgb color is : 0x00bbggrr The low-order byte contains a value for the relative intensity of red, the second byte contains a value for green, and the third byte contains a value for blue. The high-order byte must be zero. The maximum value for a single byte is 0xFF. so shouldn't it be something like this: red = color & 0x00FF; green = ( color & 0xFF00 ) >> 8; blue = ( color & 0x00FF ) >> 16; not the what is in the test? because of the following C action expression1 >> shift_value Returns expression1 with its bits shifted to the right by the shift_value. The leftmost bits are replaced with zeros if the value is nonnegative or unsigned. This result is the integer part of expression1 divided by 2 raised to the power of shift_value. If expression1 is signed, then the result is implementation specific. so the test seems to be assigning the wrong values to the RGB Correct? chris
Re: RFC : query.c d3d9 test...
Roderick Colenbrander wrote: > On Mon, Nov 23, 2009 at 9:23 PM, Stefan Dösinger > wrote: >> Am 23.11.2009 um 21:00 schrieb chris ahrendt: >>> The test fails with : >>> >>> query.c:224: Test failed: IDirect3DQuery9_GetData a 2nd time on a ended >>> query returned 0001 >> This is Windows, right? Which GPU/driver? >> >> My guess is that its ok to modify the test to accept both results. Ie, ok(hr >> == S_OK | hr == S_FALSE, "..."); >> > > I see it all the time on my Radeon 3400 on Wine. > > Roderick > > this is the wine test I run on linux and I get this all the time on my Radeon as well... which is why I was asking here... do I need to open a bug on the test to fix it since what I documented is the correct behavior chris
RFC : query.c d3d9 test...
Looking at the wine test results for the following test: query.c in the d3d9 tests directory... hr = IDirect3DQuery9_GetData(pQuery, data, IDirect3DQuery9_GetDataSize(pQuery), D3DGETDATA_FLUSH); ok(hr == S_OK, "IDirect3DQuery9_GetData on a ended query returned %08x\n", hr); hr = IDirect3DQuery9_GetData(pQuery, data, IDirect3DQuery9_GetDataSize(pQuery), D3DGETDATA_FLUSH); ok(hr == S_OK, "IDirect3DQuery9_GetData a 2nd time on a ended query returned %08x\n", hr); the MSDK says the following : IDirect3DQuery9::GetData Polls a queried resource to get the query state or a query result. For more information about queries, see Queries (Direct3D 9). Return Values The return type identifies the query state (see Queries (Direct3D 9)). The method returns S_OK if the query data is available and S_FALSE if it is not. These are considered successful return values. If the method fails when D3DGETDATA_FLUSH is used, the return value can be D3DERR_DEVICELOST. The test fails with : query.c:224: Test failed: IDirect3DQuery9_GetData a 2nd time on a ended query returned 0001 which is a S_FALSE (1) which just means the data is not available... which according to the MSDN site is an ok value to return... and is a success... so not sure what is being tested here? Is this a valid test? Also reading the MSDN the D3DGETDATA_FLUSH is supposed to flush the query so the value its returning may be ok... So If I am understanding the above code the first one should return a S_OK saying that it flushed the query code Then the second call should return a S_FALSE because the query has nothing in it. Thoughts? Explinations??? Inpuut... Chris
Re: Cpp Check Nov. 7th
Alexandre Julliard wrote: > chris ahrendt writes: > >> Alexandre Julliard wrote: >>> chris ahrendt writes: >>> >>>> Well its been a few since I ran CPP Check and so I ran it today and got >>>> the following: >>>> >>>> New CPP Check Errors for the Wine Code: >>>> >>>> [/home/cahrendt/wine-git/dlls/comctl32/imagelist.c:1908]: (error) >>>> Uninitialized variable: bmi_buf >>>> [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: >>>> fd >>>> [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: >>>> fd_cwd >>>> [/home/cahrendt/wine-git/dlls/shell32/shellord.c:416]: (error) >>>> Uninitialized variable: szText >>>> [/home/cahrendt/wine-git/dlls/shell32/shellord.c:416]: (error) >>>> Uninitialized variable: szTitle >>>> [/home/cahrendt/wine-git/dlls/shell32/shellpath.c:1360]: (error) >>>> Uninitialized variable: InfoBuffer >>>> [/home/cahrendt/wine-git/dlls/winex11.drv/xfont.c:2963]: (possible error) >>>> Resource leak: fd >>>> [/home/cahrendt/wine-git/server/mapping.c:118]: (error) Uninitialized >>>> variable: page_size >>> These are once again all false positives. I don't think there's any >>> point in continuing to post such reports, at least not until cppcheck >>> becomes more reliable. >>> >> Will report them to CPPcheck >> >> are you sure though all of these are false positives? > > Yes, there isn't a single legitimate bug in there. > Ticket open... chris
Re: Cpp Check Nov. 7th
Alexandre Julliard wrote: > chris ahrendt writes: > >> Well its been a few since I ran CPP Check and so I ran it today and got the >> following: >> >> New CPP Check Errors for the Wine Code: >> >> [/home/cahrendt/wine-git/dlls/comctl32/imagelist.c:1908]: (error) >> Uninitialized variable: bmi_buf >> [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd >> [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: >> fd_cwd >> [/home/cahrendt/wine-git/dlls/shell32/shellord.c:416]: (error) Uninitialized >> variable: szText >> [/home/cahrendt/wine-git/dlls/shell32/shellord.c:416]: (error) Uninitialized >> variable: szTitle >> [/home/cahrendt/wine-git/dlls/shell32/shellpath.c:1360]: (error) >> Uninitialized variable: InfoBuffer >> [/home/cahrendt/wine-git/dlls/winex11.drv/xfont.c:2963]: (possible error) >> Resource leak: fd >> [/home/cahrendt/wine-git/server/mapping.c:118]: (error) Uninitialized >> variable: page_size > > These are once again all false positives. I don't think there's any > point in continuing to post such reports, at least not until cppcheck > becomes more reliable. > Will report them to CPPcheck are you sure though all of these are false positives? chris
Cpp Check Nov. 7th
Well its been a few since I ran CPP Check and so I ran it today and got the following: New CPP Check Errors for the Wine Code: [/home/cahrendt/wine-git/dlls/comctl32/imagelist.c:1908]: (error) Uninitialized variable: bmi_buf [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/shell32/shellord.c:416]: (error) Uninitialized variable: szText [/home/cahrendt/wine-git/dlls/shell32/shellord.c:416]: (error) Uninitialized variable: szTitle [/home/cahrendt/wine-git/dlls/shell32/shellpath.c:1360]: (error) Uninitialized variable: InfoBuffer [/home/cahrendt/wine-git/dlls/winex11.drv/xfont.c:2963]: (possible error) Resource leak: fd [/home/cahrendt/wine-git/server/mapping.c:118]: (error) Uninitialized variable: page_size Chris
CPPcheck October 27 Git
Current Leaks: [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/winex11.drv/xfont.c:2963]: (possible error) Resource leak: fd Tool Leaks: [/home/cahrendt/wine-git/tools/fnt2bdf.c:779]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/fnt2fon.c:388]: (error) Memory leak: file_lens [/home/cahrendt/wine-git/tools/sfnt2fnt.c:877]: (error) Resource leak: ofp [/home/cahrendt/wine-git/tools/widl/write_msft.c:2536]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/winedump/pe.c:1547]: (error) Memory leak: map Ignored Test Leaks: [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (error) Array index out of bounds [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:1117]: (error) Deallocating a deallocated pointer: stream2 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:1101]: (possible error) Resource leak: stream3 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:1108]: (possible error) Resource leak: stream4 [/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem Chris
CPPCheck for Monday October 19th
Errors: [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/winex11.drv/xfont.c:2963]: (possible error) Resource leak: fd Tools Errors: [/home/cahrendt/wine-git/tools/fnt2bdf.c:779]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/fnt2fon.c:388]: (error) Memory leak: file_lens [/home/cahrendt/wine-git/tools/sfnt2fnt.c:877]: (error) Resource leak: ofp [/home/cahrendt/wine-git/tools/widl/write_msft.c:2536]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/winedump/pe.c:1547]: (error) Memory leak: map Test Errors To Ignore: [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:1117]: (error) Deallocating a deallocated pointer: stream2 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:1101]: (possible error) Resource leak: stream3 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:1108]: (possible error) Resource leak: stream4 [/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (error) Array index out of bounds Chris
CPP Check 1.1.31
[/home/cahrendt/wine-git/dlls/kernel32/resource.c:1279]: (error) Division by zero [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/winex11.drv/xfont.c:2963]: (possible error) Resource leak: fd Chris
CPPCheck run for today October 5,09
[/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd
[/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource
leak: fd_cwd
[/home/cahrendt/wine-git/dlls/winex11.drv/xfont.c:2963]: (possible
error) Resource leak: fd
[/home/cahrendt/wine-git/libs/wine/mmap.c:288]: (error) Invalid number
of character ({). Can't process file.
I think the last is a bug in CPPCheck and will report it to them
chris
cppcheck sept 18 redux
False positive ticket created for: [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW - otherwise it is redundant to check if dmW is null at line 272 what about the others? or the suggestion of adding an additional int to the array? chris
cppcheck Sept 18
[/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible error) Array index out of bounds [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW - otherwise it is redundant to check if dmW is null at line 272 chris
Regression
b5b58e423d32666581f69046c74bb19902c35c2b is first bad commit commit b5b58e423d32666581f69046c74bb19902c35c2b Author: Henri Verbeet Date: Thu Sep 17 12:35:24 2009 +0200 d3d8: Add a separate function for cube texture initialization. :04 04 8cd1752ed711799ebfb77127de399d527add5415 963c6467c8b4367b8a7bd1c1e4eece07937c13d6 M dlls [cahre...@stinky wine-git]$ Chris
apply context draw buffer
Something broke between yesterday's git tree and todays... went to run some applications and everything is slow as molasas... seems to be getting in a infinite loop in the apply context draw buffer
Sept 11 with tools and tests removed
Here is the run for Friday Sept. 11 with the tools and the tests directory results removed. [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW - otherwise it is redundant to check if dmW is null at line 272 Chris
Re: CPPCheck for Sept 8th
Nicolas Le Cam wrote: > 2009/9/9 Alexandre Julliard : >> chris ahrendt writes: >> >>> [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource >>> leak: old_cwd >> This is the only one that looks a real bug, all the rest are false >> positives. Please filter them out from future reports. >> >> -- >> Alexandre Julliard >> julli...@winehq.org >> >> >> > > Not necessary false positives. Errors in dlls/msvcrt/tests/file.c, for > example, are real but expected errors, as it's the purpose of the test > to see how it behaves on Windows in such situation. > So continue to send everything then? Since I have been running them the size has not really been that large... just let me know what you want me to send and I will send it in... Chris
Re: CPPCheck for Sept 8th
Alexandre Julliard wrote: > chris ahrendt writes: > >> [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource >> leak: old_cwd > > This is the only one that looks a real bug, all the rest are false > positives. Please filter them out from future reports. > Is there any others? So ignore the tests findings and the tools findings? Are These the ones that may be a bug then : [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:146]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:208]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW - otherwise it is redundant to check if dmW is null at line 272 These Ignore correct? [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible error) Array index out of bounds [/home/cahrendt/wine-git/tools/fnt2bdf.c:779]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/fnt2fon.c:387]: (error) Memory leak: file_lens [/home/cahrendt/wine-git/tools/makedep.c:953]: (error) Resource leak: file [/home/cahrendt/wine-git/tools/sfnt2fnt.c:877]: (error) Resource leak: ofp [/home/cahrendt/wine-git/tools/widl/write_msft.c:2536]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/winedump/msmangle.c:164]: (error) Memory leak: function_name [/home/cahrendt/wine-git/tools/winedump/pe.c:1549]: (possible error) Memory leak: map Chris
Re: CPPCheck for Sept 8th
Alexandre Julliard wrote: > chris ahrendt writes: > >> [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource >> leak: old_cwd > > This is the only one that looks a real bug, all the rest are false > positives. Please filter them out from future reports. > Alexandre, I will filter them as best I can going forward... Chris
CPPCheck for Sept 8th
[/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible error) Array index out of bounds [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:146]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:208]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW - otherwise it is redundant to check if dmW is null at line 272 [/home/cahrendt/wine-git/tools/fnt2bdf.c:779]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/fnt2fon.c:387]: (error) Memory leak: file_lens [/home/cahrendt/wine-git/tools/makedep.c:953]: (error) Resource leak: file [/home/cahrendt/wine-git/tools/sfnt2fnt.c:877]: (error) Resource leak: ofp [/home/cahrendt/wine-git/tools/widl/write_msft.c:2536]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/winedump/msmangle.c:164]: (error) Memory leak: function_name [/home/cahrendt/wine-git/tools/winedump/pe.c:1549]: (possible error) Memory leak: map This is using thursdays git tree of CPPCheck.. please let me know if there are FP's so I can report them. Chris p.s. Thanks stephan for pointing out I sent it to the wrong list =D
CPP Run for Sept 3
[../wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [../wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [../wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [../wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem [../wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd [../wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [../wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [../wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible error) Array index out of bounds [../wine-git/dlls/wineoss.drv/mmaux.c:150]: (error) Resource leak: mixer [../wine-git/dlls/wineoss.drv/mmaux.c:211]: (error) Resource leak: mixer [../wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW - otherwise it is redundant to check if dmW is null at line 272 [../wine-git/programs/oleview/pane.c:152]: (error) Possible null pointer dereference: hWndCreated [../wine-git/tools/fnt2bdf.c:779]: (error) Resource leak: fd [../wine-git/tools/fnt2fon.c:387]: (error) Memory leak: file_lens [../wine-git/tools/makedep.c:953]: (error) Resource leak: file [../wine-git/tools/sfnt2fnt.c:877]: (error) Resource leak: ofp [../wine-git/tools/widl/write_msft.c:2536]: (error) Resource leak: fd [../wine-git/tools/winedump/msmangle.c:164]: (error) Memory leak: function_name [../wine-git/tools/winedump/pe.c:1549]: (possible error) Memory leak: map Chris
Re: cpp check run monday Aug 31
ok will report a false positive thanks chris - Original Message From: Vincent Povirk To: chris ahrendt Cc: wine-devel@winehq.org Sent: Tuesday, September 1, 2009 9:30:46 AM Subject: Re: cpp check run monday Aug 31 > [/home/cahrendt/wine-git/dlls/windowscodecs/bmpencode.c:336]: (error) > Division by zero > [/home/cahrendt/wine-git/dlls/windowscodecs/bmpencode.c:337]: (error) > Division by zero http://source.winehq.org/git/wine.git/?a=blob;f=dlls/windowscodecs/bmpencode.c;h=11c39e898675122eb24df6a3a0ba9a911c95e3d0;hb=HEAD#l336 I'm going to need someone to explain to me how a division by a literal 0.0254 can be a "Division by zero". -- Vincent Povirk
cpp check run monday Aug 31
I ran CPP check against the monday git tree using the latest CPP check off their git tree. here is the result : [/home/cahrendt/wine-git/dlls/ddraw/tests/d3d.c:320]: (error) Division by zero [/home/cahrendt/wine-git/dlls/ddraw/tests/d3d.c:336]: (error) Division by zero [/home/cahrendt/wine-git/dlls/ddraw/tests/d3d.c:340]: (error) Division by zero [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem [/home/cahrendt/wine-git/dlls/ntdll/directory.c:2339]: (error) Resource leak: old_cwd [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible error) Array index out of bounds [/home/cahrendt/wine-git/dlls/sane.ds/ui.c:842]: (error) Division by zero [/home/cahrendt/wine-git/dlls/sane.ds/ui.c:843]: (error) Division by zero [/home/cahrendt/wine-git/dlls/sane.ds/ui.c:863]: (error) Division by zero [/home/cahrendt/wine-git/dlls/windowscodecs/bmpencode.c:336]: (error) Division by zero [/home/cahrendt/wine-git/dlls/windowscodecs/bmpencode.c:337]: (error) Division by zero [/home/cahrendt/wine-git/dlls/wined3d/wined3d_private.h:218]: (error) Division by zero [/home/cahrendt/wine-git/dlls/wined3d/wined3d_private.h:219]: (error) Division by zero [/home/cahrendt/wine-git/dlls/wined3d/wined3d_private.h:240]: (error) Division by zero [/home/cahrendt/wine-git/dlls/wined3d/wined3d_private.h:241]: (error) Division by zero [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:150]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineoss.drv/mmaux.c:211]: (error) Resource leak: mixer [/home/cahrendt/wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW - otherwise it is redundant to check if dmW is null at line 272 [/home/cahrendt/wine-git/programs/oleview/pane.c:152]: (error) Possible null pointer dereference: hWndCreated [/home/cahrendt/wine-git/tools/fnt2bdf.c:779]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/fnt2fon.c:387]: (error) Memory leak: file_lens [/home/cahrendt/wine-git/tools/makedep.c:953]: (error) Resource leak: file [/home/cahrendt/wine-git/tools/sfnt2fnt.c:877]: (error) Resource leak: ofp [/home/cahrendt/wine-git/tools/widl/write_msft.c:2536]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/winedump/msmangle.c:164]: (possible error) Memory leak: function_name [/home/cahrendt/wine-git/tools/winedump/pe.c:1549]: (possible error) Memory leak: map chris
Re: Weekly cppcheck run against Aug 27 Git Tree
Ok CPPCheck guys have repired the false positive but now get this: $ ./cppcheck -q -a ../wine/wine/dlls/wineoss.drv/mixer.c ../wine/wine/dlls/wineoss.drv/mixer.c:576: (error) Resource leak: mixer ../wine/wine/dlls/wineoss.drv/mixer.c:600: (error) Resource leak: mixer ../wine/wine/dlls/wineoss.drv/mixer.c:1454: (error) Resource leak: mixer can someone tell me if these are false positives as well? chris
Re: Weekly cppcheck run against Aug 27 Git Tree
James McKenzie wrote: > chris ahrendt wrote: > >> - Original Message >> From: Ben Klein >> To: chris ahrendt >> Cc: wine-devel@winehq.org >> Sent: Thursday, August 27, 2009 10:06:56 PM >> Subject: Re: Weekly cppcheck run against Aug 27 Git Tree >> >> 2009/8/28 chris ahrendt : >> >> >>> Mike Kaplinskiy wrote: >>> >>> >>>> On Thu, Aug 27, 2009 at 3:52 PM, chris ahrendt wrote: >>>> >>>> >>>> >>>>> This is the result of running cppcheck 1.35 with the --all parm against >>>>> the august 27th Git tree: >>>>> >>>>> [../wine-git/dlls/dbghelp/msc.c:88]: (possible error) Array index out of >>>>> bounds >>>>> [../wine-git/dlls/dbghelp/msc.c:89]: (possible error) Array index out of >>>>> bounds >>>>> >>>>> >>>>> >>>> False positive, apparently the numbers are hardcoded as: >>>> 72 charmsg[128]; >>>> 88 msg[10 + 3 * 16] = ' '; // = 58<127 >>>> 89 msg[10 + 3 * 16 + 1 + 16] = '\0'; // = 75<127 >>>> >>>> >>> Mike While yes the hard coded one above is a false positive... I would >>> argue its still a bug that probably needs to get fixed... >>> >>> >> >> >>> I don't follow this logic. How is it a bug (in Wine) exactly? >>> >>> >> I thought one of the programming standards was the fact you don't hard code >> values IE 10+3*16... >> it should probably be : >> >> msg_blank = 10+3*16; // These go into header files >> msg_length = 128; // This goes into header file >> >> char msg[msg_length]; >> memset(msg, 0, sizeof(msg)); >> memset(msg, ' ', msg_blank); // or it could even be msg[msg_blank] = ' '; if >> only position 58 needs to be a ' ' , but I prefer the first method. >> >> does pretty much the same thing except for one point. >> Whatever is in the local stack at the point of assigning the msg buffer will >> be still there unless you initialise it to null. >> >> >> > I like your logic, but why not just do this: > > msg_blank= 58; > msg_yada_yada=75; > msg_length=128; > > This sets all of the variables using plain values and then they can be > updated as necessary. > > James McKenzie > > > > > same thing =D Chris
Re: Weekly cppcheck run against Aug 27 Git Tree
- Original Message From: Ben Klein To: chris ahrendt Cc: wine-devel@winehq.org Sent: Thursday, August 27, 2009 10:06:56 PM Subject: Re: Weekly cppcheck run against Aug 27 Git Tree 2009/8/28 chris ahrendt : > Mike Kaplinskiy wrote: >> On Thu, Aug 27, 2009 at 3:52 PM, chris ahrendt wrote: >> >>> This is the result of running cppcheck 1.35 with the --all parm against >>> the august 27th Git tree: >>> >>> [../wine-git/dlls/dbghelp/msc.c:88]: (possible error) Array index out of >>> bounds >>> [../wine-git/dlls/dbghelp/msc.c:89]: (possible error) Array index out of >>> bounds >>> >> >> False positive, apparently the numbers are hardcoded as: >> 72 charmsg[128]; >> 88 msg[10 + 3 * 16] = ' '; // = 58<127 >> 89 msg[10 + 3 * 16 + 1 + 16] = '\0'; // = 75<127 > > Mike While yes the hard coded one above is a false positive... I would > argue its still a bug that probably needs to get fixed... >I don't follow this logic. How is it a bug (in Wine) exactly? I thought one of the programming standards was the fact you don't hard code values IE 10+3*16... it should probably be : msg_blank = 10+3*16; // These go into header files msg_length = 128; // This goes into header file char msg[msg_length]; memset(msg, 0, sizeof(msg)); memset(msg, ' ', msg_blank); // or it could even be msg[msg_blank] = ' '; if only position 58 needs to be a ' ' , but I prefer the first method. does pretty much the same thing except for one point. Whatever is in the local stack at the point of assigning the msg buffer will be still there unless you initialise it to null. chris
Re: Weekly cppcheck run against Aug 27 Git Tree
Mike Kaplinskiy wrote:
> On Thu, Aug 27, 2009 at 3:52 PM, chris ahrendt wrote:
>
>> This is the result of running cppcheck 1.35 with the --all parm against
>> the august 27th Git tree:
>>
>> [../wine-git/dlls/dbghelp/msc.c:88]: (possible error) Array index out of
>> bounds
>> [../wine-git/dlls/dbghelp/msc.c:89]: (possible error) Array index out of
>> bounds
>>
>
> False positive, apparently the numbers are hardcoded as:
> 72 charmsg[128];
> 88 msg[10 + 3 * 16] = ' '; // = 58<127
> 89 msg[10 + 3 * 16 + 1 + 16] = '\0'; // = 75<127
>
>
>> [../wine-git/dlls/shell32/cpanelfolder.c:562]: (error) Possible null
>> pointer dereference: rgfInOut
>> [../wine-git/dlls/shell32/shfldr_desktop.c:437]: (error) Possible null
>> pointer dereference: rgfInOut
>> [../wine-git/dlls/shell32/shfldr_fs.c:577]: (error) Possible null
>> pointer dereference: rgfInOut
>> [../wine-git/dlls/shell32/shfldr_mycomp.c:474]: (error) Possible null
>> pointer dereference: rgfInOut
>> [../wine-git/dlls/shell32/shfldr_netplaces.c:352]: (error) Possible null
>> pointer dereference: rgfInOut
>>
>
> It doesn't like the ternary operator? These lines are TRACE lines with
> one of the args being ``rgfInOut ? *rgfInOut : 0''. False positive.
>
>
>> [../wine-git/dlls/user32/tests/msg.c:63]: (error) Invalid number of
>> character ({). Can't process file.
>> [../wine-git/dlls/winealsa.drv/waveinit.c:745]: (possible error) Buffer
>> overrun
>>
>
> 739 char defaultpcmname[256];
> 745 sprintf(defaultpcmname, "default");
>
> Something is wrong with cppcheck... False positive.
>
>
>> [../wine-git/dlls/wined3d/arb_program_shader.c:907]: (possible error)
>> Buffer overrun
>> [../wine-git/dlls/wined3d/arb_program_shader.c:915]: (possible error)
>> Buffer overrun
>> [../wine-git/dlls/wined3d/glsl_shader.c:3416]: (possible error) Buffer
>> overrun
>> [../wine-git/dlls/wined3d/glsl_shader.c:3418]: (possible error) Buffer
>> overrun
>> [../wine-git/dlls/wined3d/glsl_shader.c:3519]: (possible error) Buffer
>> overrun
>> [../wine-git/dlls/wined3d/glsl_shader.c:3521]: (possible error) Buffer
>> overrun
>>
>
> Not checking those - i don't even pretend to understand how modern
> graphics works.
>
>
>> [../wine-git/dlls/wineoss.drv/mixer.c:1458]: (possible error) Buffer overrun
>>
>
> So...it picks
> 1455 char name[32];
> 1458 sprintf(name, "/dev/mixer");
>
> as an error, but not:
>
> 1460 sprintf(name, "/dev/mixer%d", i);
>
> False positive.
>
>
>> [../wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer
>> dereference: dmW
>>
>
> This one is actually a bug, the null check is below this line. All the
> callers check for nulls, though.
>
>
>> [../wine-git/programs/oleview/pane.c:152]: (error) Possible null pointer
>> dereference: hWndCreated
>>
>
> Also a bug, and a very real one. Coincidentally, the null check on the
> next line is also wrong (should be if (!*hWndCreated) )
>
>
>> [../wine-git/programs/winetest/main.c:114]: (possible error) Buffer overrun
>> [../wine-git/programs/winetest/main.c:116]: (possible error) Buffer overrun
>> [../wine-git/programs/winetest/main.c:119]: (possible error) Buffer overrun
>> [../wine-git/programs/winetest/main.c:121]: (possible error) Buffer overrun
>>
>
> More of sprintf with just a string nonsense. False positive.
>
>
>> [../wine-git/server/file.c:235]: (possible error) Buffer overrun
>>
>
> Also sprintf nonsense, but slightly more dangerous. The buffer is
> declared with [16] and the string is of length 14+1, so a few more
> bytes wouldn't hurt. :)
>
>> Chris
>>
>>
>
> If someone could send patches for the few bugs that would be nice.
>
> Chris - cppcheck is clearly crazy about sprintf's and ternary
> operators. You might want to report that.
>
> Mike.
>
>
>
Mike While yes the hard coded one above is a false positive... I would
argue its still a bug that probably needs to get fixed...
chris
Re: Weekly cppcheck run against Aug 27 Git Tree
Mike Kaplinskiy wrote:
> On Thu, Aug 27, 2009 at 3:52 PM, chris ahrendt wrote:
>
>> This is the result of running cppcheck 1.35 with the --all parm against
>> the august 27th Git tree:
>>
>> [../wine-git/dlls/dbghelp/msc.c:88]: (possible error) Array index out of
>> bounds
>> [../wine-git/dlls/dbghelp/msc.c:89]: (possible error) Array index out of
>> bounds
>>
>
> False positive, apparently the numbers are hardcoded as:
> 72 charmsg[128];
> 88 msg[10 + 3 * 16] = ' '; // = 58<127
> 89 msg[10 + 3 * 16 + 1 + 16] = '\0'; // = 75<127
>
>
>> [../wine-git/dlls/shell32/cpanelfolder.c:562]: (error) Possible null
>> pointer dereference: rgfInOut
>> [../wine-git/dlls/shell32/shfldr_desktop.c:437]: (error) Possible null
>> pointer dereference: rgfInOut
>> [../wine-git/dlls/shell32/shfldr_fs.c:577]: (error) Possible null
>> pointer dereference: rgfInOut
>> [../wine-git/dlls/shell32/shfldr_mycomp.c:474]: (error) Possible null
>> pointer dereference: rgfInOut
>> [../wine-git/dlls/shell32/shfldr_netplaces.c:352]: (error) Possible null
>> pointer dereference: rgfInOut
>>
>
> It doesn't like the ternary operator? These lines are TRACE lines with
> one of the args being ``rgfInOut ? *rgfInOut : 0''. False positive.
>
>
>> [../wine-git/dlls/user32/tests/msg.c:63]: (error) Invalid number of
>> character ({). Can't process file.
>> [../wine-git/dlls/winealsa.drv/waveinit.c:745]: (possible error) Buffer
>> overrun
>>
>
> 739 char defaultpcmname[256];
> 745 sprintf(defaultpcmname, "default");
>
> Something is wrong with cppcheck... False positive.
>
>
>> [../wine-git/dlls/wined3d/arb_program_shader.c:907]: (possible error)
>> Buffer overrun
>> [../wine-git/dlls/wined3d/arb_program_shader.c:915]: (possible error)
>> Buffer overrun
>> [../wine-git/dlls/wined3d/glsl_shader.c:3416]: (possible error) Buffer
>> overrun
>> [../wine-git/dlls/wined3d/glsl_shader.c:3418]: (possible error) Buffer
>> overrun
>> [../wine-git/dlls/wined3d/glsl_shader.c:3519]: (possible error) Buffer
>> overrun
>> [../wine-git/dlls/wined3d/glsl_shader.c:3521]: (possible error) Buffer
>> overrun
>>
>
> Not checking those - i don't even pretend to understand how modern
> graphics works.
>
>
>> [../wine-git/dlls/wineoss.drv/mixer.c:1458]: (possible error) Buffer overrun
>>
>
> So...it picks
> 1455 char name[32];
> 1458 sprintf(name, "/dev/mixer");
>
> as an error, but not:
>
> 1460 sprintf(name, "/dev/mixer%d", i);
>
> False positive.
>
>
>> [../wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer
>> dereference: dmW
>>
>
> This one is actually a bug, the null check is below this line. All the
> callers check for nulls, though.
>
>
>> [../wine-git/programs/oleview/pane.c:152]: (error) Possible null pointer
>> dereference: hWndCreated
>>
>
> Also a bug, and a very real one. Coincidentally, the null check on the
> next line is also wrong (should be if (!*hWndCreated) )
>
>
>> [../wine-git/programs/winetest/main.c:114]: (possible error) Buffer overrun
>> [../wine-git/programs/winetest/main.c:116]: (possible error) Buffer overrun
>> [../wine-git/programs/winetest/main.c:119]: (possible error) Buffer overrun
>> [../wine-git/programs/winetest/main.c:121]: (possible error) Buffer overrun
>>
>
> More of sprintf with just a string nonsense. False positive.
>
>
>> [../wine-git/server/file.c:235]: (possible error) Buffer overrun
>>
>
> Also sprintf nonsense, but slightly more dangerous. The buffer is
> declared with [16] and the string is of length 14+1, so a few more
> bytes wouldn't hurt. :)
>
>> Chris
>>
>>
>
> If someone could send patches for the few bugs that would be nice.
>
> Chris - cppcheck is clearly crazy about sprintf's and ternary
> operators. You might want to report that.
>
> Mike.
>
>
>
Sending the report now.
chris
Weekly cppcheck run against Aug 27 Git Tree
This is the result of running cppcheck 1.35 with the --all parm against
the august 27th Git tree:
[../wine-git/dlls/dbghelp/msc.c:88]: (possible error) Array index out of
bounds
[../wine-git/dlls/dbghelp/msc.c:89]: (possible error) Array index out of
bounds
[../wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a
deallocated pointer: stream2
[../wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3
[../wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4
[../wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory
leak: mem
[../wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd
[../wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible error) Array
index out of bounds
[../wine-git/dlls/shell32/cpanelfolder.c:562]: (error) Possible null
pointer dereference: rgfInOut
[../wine-git/dlls/shell32/shfldr_desktop.c:437]: (error) Possible null
pointer dereference: rgfInOut
[../wine-git/dlls/shell32/shfldr_fs.c:577]: (error) Possible null
pointer dereference: rgfInOut
[../wine-git/dlls/shell32/shfldr_mycomp.c:474]: (error) Possible null
pointer dereference: rgfInOut
[../wine-git/dlls/shell32/shfldr_netplaces.c:352]: (error) Possible null
pointer dereference: rgfInOut
[../wine-git/dlls/user32/tests/msg.c:63]: (error) Invalid number of
character ({). Can't process file.
[../wine-git/dlls/winealsa.drv/waveinit.c:745]: (possible error) Buffer
overrun
[../wine-git/dlls/wined3d/arb_program_shader.c:907]: (possible error)
Buffer overrun
[../wine-git/dlls/wined3d/arb_program_shader.c:915]: (possible error)
Buffer overrun
[../wine-git/dlls/wined3d/glsl_shader.c:3416]: (possible error) Buffer
overrun
[../wine-git/dlls/wined3d/glsl_shader.c:3418]: (possible error) Buffer
overrun
[../wine-git/dlls/wined3d/glsl_shader.c:3519]: (possible error) Buffer
overrun
[../wine-git/dlls/wined3d/glsl_shader.c:3521]: (possible error) Buffer
overrun
[../wine-git/dlls/wineoss.drv/mixer.c:1458]: (possible error) Buffer overrun
[../wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer
dereference: dmW
[../wine-git/programs/oleview/pane.c:152]: (error) Possible null pointer
dereference: hWndCreated
[../wine-git/programs/winetest/main.c:114]: (possible error) Buffer overrun
[../wine-git/programs/winetest/main.c:116]: (possible error) Buffer overrun
[../wine-git/programs/winetest/main.c:119]: (possible error) Buffer overrun
[../wine-git/programs/winetest/main.c:121]: (possible error) Buffer overrun
[../wine-git/server/file.c:235]: (possible error) Buffer overrun
[../wine-git/tools/fnt2bdf.c:656]: (error) Resource leak: fd
[../wine-git/tools/fnt2fon.c:303]: (error) Memory leak: file_lens
[../wine-git/tools/makedep.c:337]: (error) Resource leak: file
[../wine-git/tools/widl/write_msft.c:2540]: (error) Deallocating a
deallocated pointer: fd
[../wine-git/tools/winedump/pe.c:1549]: (possible error) Memory leak: map
Chris
Re: CPPCheck Run for Friday August 21
Mike Kaplinskiy wrote: > On Fri, Aug 21, 2009 at 9:21 PM, chris ahrendt wrote: > >> [../wine-git/dlls/msvcrt/tests/file.c:997]: (error) Resource leak: stream1 >> [../wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a >> deallocated pointer: stream2 >> [../wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 >> [../wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 >> [../wine-git/dlls/msvcrt/tests/heap.c:424]: (error) Deallocating a >> deallocated pointer: mem >> [../wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd >> [../wine-git/dlls/rpcrt4/tests/server.c:1189]: (all) Array index out of >> bounds >> > > False positive. Doesn't like the FIELD_OFFSET macro for alloc. > > >> [../wine-git/server/handle.c:201]: (error) Memory leak: new_entries >> > > This is probably the only one here that sticks out, but afaict, it's > not a leak. There's somewhat convoluted logic involved (if > count==table->count, we don't reallocate; if reallocation fails...the > previous pointer shouldn't be deallocated, and new_entries=NULL > anyway). Its a false positive. This seems like something it shouldn't > catch though, so might want to report this bug to cppcheck devs. > > >> [../wine-git/tools/fnt2bdf.c:656]: (error) Resource leak: fd >> [../wine-git/tools/fnt2fon.c:303]: (error) Memory leak: file_lens >> [../wine-git/tools/makedep.c:953]: (error) Resource leak: file >> [../wine-git/tools/widl/write_msft.c:2540]: (error) Deallocating a >> deallocated pointer: fd >> [../wine-git/tools/winedump/pe.c:1549]: (all) Memory leak: map >> >> >> Chris >> >> >> > > Thanks for running these, keeps the code nicely in check. > > Mike. > > > I reran it on 1.1.28 and the result is the same so will report the false positive to cpp guys... Your welcome ... its something to do for the devs =D chris
CPPCheck Run for Friday August 21
[../wine-git/dlls/msvcrt/tests/file.c:997]: (error) Resource leak: stream1 [../wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [../wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [../wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [../wine-git/dlls/msvcrt/tests/heap.c:424]: (error) Deallocating a deallocated pointer: mem [../wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [../wine-git/dlls/rpcrt4/tests/server.c:1189]: (all) Array index out of bounds [../wine-git/server/handle.c:201]: (error) Memory leak: new_entries [../wine-git/tools/fnt2bdf.c:656]: (error) Resource leak: fd [../wine-git/tools/fnt2fon.c:303]: (error) Memory leak: file_lens [../wine-git/tools/makedep.c:953]: (error) Resource leak: file [../wine-git/tools/widl/write_msft.c:2540]: (error) Deallocating a deallocated pointer: fd [../wine-git/tools/winedump/pe.c:1549]: (all) Memory leak: map Chris
CPPcheck weekly run off thursdays GIT tree
[../wine-git/dlls/msvcrt/tests/file.c:997]: (error) Resource leak: stream1 [../wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [../wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [../wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [../wine-git/dlls/msvcrt/tests/heap.c:424]: (error) Deallocating a deallocated pointer: mem [../wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [../wine-git/dlls/rpcrt4/tests/server.c:1189]: (all) Array index out of bounds [../wine-git/dlls/wined3d/arb_program_shader.c:820]: (all) Buffer overrun [../wine-git/dlls/wined3d/arb_program_shader.c:821]: (all) Buffer overrun [../wine-git/dlls/wined3d/arb_program_shader.c:966]: (all) Buffer overrun [../wine-git/dlls/wined3d/arb_program_shader.c:977]: (all) Buffer overrun [../wine-git/dlls/wined3d/arb_program_shader.c:988]: (all) Buffer overrun [../wine-git/server/handle.c:201]: (error) Memory leak: new_entries [../wine-git/tools/fnt2bdf.c:656]: (error) Resource leak: fd [../wine-git/tools/fnt2fon.c:303]: (error) Memory leak: file_lens [../wine-git/tools/makedep.c:953]: (error) Resource leak: file [../wine-git/tools/widl/write_msft.c:2540]: (error) Deallocating a deallocated pointer: fd [../wine-git/tools/winedump/pe.c:1549]: (all) Memory leak: map Chris
Re: wine-devel Digest, Vol 49, Issue 21
> > Subject: > re: cppcheck run against 1.27 > From: > Dan Kegel > Date: > Sat, 8 Aug 2009 15:53:25 -0700 > To: > wine-devel@winehq.org > > To: > wine-devel@winehq.org > > > Chris wrote: > >> ... >> [../wine-git/tools/widl/write_msft.c:2540]: (error) Deallocating a >> deallocated pointer: fd - This just means your freeing an already freed >> resource... This is more of a warning than anything >> > > Double frees are serious errors... double closes not so much. > I don't see either on that line, though...? > - Dan > I can run it with the --all option to see if it gives any clarification Chris
Re: cppcheck run against 1.27
Marcus Meissner wrote: > On Fri, Aug 07, 2009 at 06:36:36PM -0700, chris ahrendt wrote: > >> [../wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd >> > > I do not fully understand the code (keep fd open to have to lock > existing?), but it is in a fatal exit path. > >> [../wine-git/tools/fnt2bdf.c:219]: (error) Resource leak: fp >> [../wine-git/tools/fnt2bdf.c:653]: (error) Resource leak: fd >> > > Fix submitted, seem necessary. > > >> [../wine-git/tools/fnt2fon.c:304]: (error) Memory leak: file_lens >> > > Fix submitted, but program is shortlived. > > >> [../wine-git/tools/widl/write_msft.c:2540]: (error) Deallocating a >> deallocated pointer: fd >> > > I do not understand what it mislikes about it. I think the detection > is wrong. > > >> [../wine-git/tools/winebuild/res16.c:187]: (error) Resource leak: fd >> > > Fix submitted. Small issue though. > > >> [../wine-git/tools/winedump/pe.c:1549]: (error) Memory leak: map >> > > Fix submitted. Small issue though. > > Ciao, Marcus > > > here is what its checking for : Standard checks that are always used * out of bounds * Using 'memfunc' on class * Using 'memfunc' on struct that contains a 'std::classname' * Class Base which is inherited by class Derived does not have a virtual destructor * Mismatching allocation and deallocation: varname * Memory leak <http://en.wikipedia.org/wiki/Memory_leak>: varname * Resource leak <http://en.wikipedia.org/wiki/Resource_leak>: varname * Deallocating a deallocated pointer: varname * Using 'varname' after it is deallocated / released * The given size sz is mismatching * Invalid radix in call to strtol <http://en.wikipedia.org/wiki/Strtol> or strtoul. Must be 0 or 2-36 * Overlapping data buffer varname * Unsigned division. The result will be wrong. * Unusual pointer arithmetic * Returning pointer to local array variable * Same iterator is used with both container1 and container2 * Dangerous usage of erase * After push_back or push_front, the iterator 'iterator_name' may be invalid * Wrong assignment of an auto-variable to an effective parameter of a function * Return of the address of an auto-variable * Division by zero * STL <http://en.wikipedia.org/wiki/Standard_Template_Library>: check usage of iterators after erase, as erase invalidates the iterator * STL: check usage of iterators and pointers after push_back and push_front. If using a vector the iterator or pointer may become invalid. * STL: Range checks with iterators should use != instead of < I have not run it with the following : Extra checks that you enable with "--all" These checks are not part of the standard checking because they produce false positives. * Array index out of bounds * Buffer overrun * Dangerous usage of strncat <http://en.wikipedia.org/wiki/Strcat>, possible buffer overrun * Memory leak: varname * The size argument is given as a char constant Extra checks that you enable with "--style" * The class 'classname' has no constructor * Member variable not initialized in the constructor 'classname::varname' * Unused private function 'classname::funcname' * 'operator=' should return something * C-style pointer casting * Redundant condition. It is safe to deallocate a NULL pointer * Redundant condition. The remove function in the STL will not do anything if element doesn't exist * Found redundant if condition - 'if (condition);' * struct or union member 'structname::varname' is never used * Function parameter 'parname' is passed by value. It could be passed by reference instead. * Redundant code: Found a statement that begins with type constant * Warning - using char variable as array index * Warning - using char variable in bit operation * Condition is always truefalse Checks that are enabled when both "--all" and "--style" is given * Warning: Division with signed and unsigned operators When giving "--unused-functions" * The function 'funcname' is never used I am going to start running with the --all flag going forward. So the leak with fd cppcheck thinks that you have an exit path that will leave the fd allocated still without freeing the resource. [../wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd so this exits without freeing the resource. [../wine-git/tools/widl/write_msft.c:2540]: (error) Deallocating a deallocated pointer: fd - This just means your freeing an already freed resource... This is more of a warning than anything Chris
cppcheck run against 1.27
[../wine-git/dlls/msvcrt/tests/file.c:997]: (error) Resource leak: stream1 [../wine-git/dlls/msvcrt/tests/file.c:997]: (error) Resource leak: stream4 [../wine-git/dlls/msvcrt/tests/heap.c:424]: (error) Deallocating a deallocated pointer: mem [../wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [../wine-git/tools/fnt2bdf.c:219]: (error) Resource leak: fp [../wine-git/tools/fnt2bdf.c:653]: (error) Resource leak: fd [../wine-git/tools/fnt2fon.c:304]: (error) Memory leak: file_lens [../wine-git/tools/widl/write_msft.c:2540]: (error) Deallocating a deallocated pointer: fd [../wine-git/tools/winebuild/res16.c:187]: (error) Resource leak: fd [../wine-git/tools/winedump/pe.c:1549]: (error) Memory leak: map Latest Check against the 1.27 Tree Chris
Re: Interesting find with cppcheck..
Scott Ritchie wrote: > chris ahrendt wrote: > >> Austin English wrote: >> >>> On Tue, Aug 4, 2009 at 2:07 PM, Juan Lang wrote: >>> >>> >>>>> If the group wants I can run this daily when I run wine test as well.. >>>>> and post it here just let me know >>>>> >>>>> >>>> Probably not. Most of the remaining leaks are in the tests or the >>>> tools. Since these are short-lived programs, the leaks will get >>>> plugged as soon as the programs end anyway. The only exception is the >>>> ntdll one, and it only happens when ntdll can't connect to the >>>> wineserver, and the process is dying anyway. >>>> >>>> >>> Still wouldn't hurt to fix them. >>> >>> It may not be worth running daily, but perhaps weekly and see if >>> anything new pops up. >>> >>> >>> >> Ok will run it weekly then on fridays or want me to do it on major >> release's? >> >> chris >> >> > > How about just before major releases? ;) > > Thanks, > Scott Ritchie > > > Ok what I will try and do is when . releases go out I will run them and post the results here chris
Re: Interesting find with cppcheck..
Austin English wrote: > On Tue, Aug 4, 2009 at 2:07 PM, Juan Lang wrote: > >>> If the group wants I can run this daily when I run wine test as well.. >>> and post it here just let me know >>> >> Probably not. Most of the remaining leaks are in the tests or the >> tools. Since these are short-lived programs, the leaks will get >> plugged as soon as the programs end anyway. The only exception is the >> ntdll one, and it only happens when ntdll can't connect to the >> wineserver, and the process is dying anyway. >> > > Still wouldn't hurt to fix them. > > It may not be worth running daily, but perhaps weekly and see if > anything new pops up. > > Ok will run it weekly then on fridays or want me to do it on major release's? chris
Re: Interesting find with cppcheck..
Juan Lang wrote: > Hi Chris, > > >> [../wine-git/dlls/crypt32/rootstore.c:346]: (error) Resource leak: dir >> > > I just sent a patch to fix this. Thanks! > --Juan > > > If the group wants I can run this daily when I run wine test as well.. and post it here just let me know Chris
Interesting find with cppcheck..
I was working on something else and using cppcheck to make sure I was not having a memory leak and so forth and decided to try it on wine here is what is the results of the wine git tree : [../wine-git/dlls/crypt32/rootstore.c:346]: (error) Resource leak: dir [../wine-git/dlls/msvcrt/tests/file.c:997]: (error) Resource leak: stream1 [../wine-git/dlls/msvcrt/tests/file.c:997]: (error) Resource leak: stream4 [../wine-git/dlls/msvcrt/tests/heap.c:424]: (error) Deallocating a deallocated pointer: mem [../wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [../wine-git/tools/fnt2bdf.c:219]: (error) Resource leak: fp [../wine-git/tools/fnt2bdf.c:653]: (error) Resource leak: fd [../wine-git/tools/fnt2fon.c:304]: (error) Memory leak: file_lens [../wine-git/tools/widl/write_msft.c:2540]: (error) Deallocating a deallocated pointer: fd [../wine-git/tools/winebuild/res16.c:187]: (error) Resource leak: fd [../wine-git/tools/winedump/pe.c:1549]: (error) Memory leak: map Not sure if I need to write up a bug for this or what... and no I cant touch the code due to NDA issues. Chris
dotests script
Does anyone have the dotests script they could send me ... I moved to a new machine and lost the script. Went to the wiki and it fails to find it when I click on the link. I get an error stating that I am unable to add an attachment (even after logging in). Chris
RDo we still need the regression test for 1.1.23 ?
to see what patch caused the failure on non NVIDIA cards? Chris
Re: wine-devel Digest, Vol 47, Issue 32
Did we find out what the regression is for 1.1.23 that caused the ATI and other non NVIDIA cards to start failing? Chris
Re: Latest Git build 7aeffc442cc1 for Wine 1.1.23
Using this attached Reg File Is still a no go... same... (I forgot the Direct3D tag but added it and no change) Chris rendering3.Reg Description: Binary data
Re: Latest Git build 7aeffc442cc1 for Wine 1.1.23
On 06/05/2009 09:16 PM, Austin English wrote: > On Fri, Jun 5, 2009 at 8:03 PM, chris ahrendt wrote: > >> On 06/05/2009 08:15 PM, Austin English wrote: >> >>> On Fri, Jun 5, 2009 at 7:11 PM, chris ahrendt >>> wrote: >>> >>> >>>> Tried it several times.. and different iterations of the registry keys >>>> (you will find them attached) and both cases it fails the same way any >>>> of the d3d tests will fail or the machine locks up. >>>> >>>> >>> >> >> > Use that attached .reg file. > > > Which one I attached two and neither of them worked at all.. Chris
Re: Latest Git build 7aeffc442cc1 for Wine 1.1.23
On 06/05/2009 08:15 PM, Austin English wrote: > On Fri, Jun 5, 2009 at 7:11 PM, chris ahrendt wrote: > >> Tried it several times.. and different iterations of the registry keys >> (you will find them attached) and both cases it fails the same way any >> of the d3d tests will fail or the machine locks up. >> >
Re: Latest Git build 7aeffc442cc1 for Wine 1.1.23
Tried it several times.. and different iterations of the registry keys (you will find them attached) and both cases it fails the same way any of the d3d tests will fail or the machine locks up. rendering.Reg Description: Binary data rendering2.Reg Description: Binary data
Re: Latest Git build 7aeffc442cc1 for Wine 1.1.23
On 06/05/2009 05:10 PM, Roderick Colenbrander wrote: > Check the useful registry keys page at wiki.winehq.org (it is > Direct3D/OffscreenRenderingMethod) > > Roderick > > On Fri, Jun 5, 2009 at 10:41 PM, chris ahrendt wrote: > >> On 06/05/2009 04:32 PM, Roderick Colenbrander wrote: >> >>> As of Wine 1.1.23 wined3d made FBOs the default offscreen rendering >>> method. If you are using a non-nvidia card (those in general have >>> buggier drivers) that could explain all the failures. Setting >>> OffscreenRenderingMethod to backbuffer restores the old behavior. >>> >>> Roderick >>> >>> On Fri, Jun 5, 2009 at 10:04 PM, chris ahrendt >>> wrote: >>> >>> >>>> Something majorly changed and is wrong with the latest GIT tree. >>>> Between the comits yesterday and today 90% of the tests get exceptions >>>> or fail. >>>> All of the d3d tests get a process exception and fail with a dialog box. >>>> >>>> >>>> Ideas? >>>> >>>> Chris >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> where do I set that? >> >> >> >> >> >> >> >> >> > > Added the registry key and no go... still failure... Chris
Re: Latest Git build 7aeffc442cc1 for Wine 1.1.23
On 06/05/2009 04:32 PM, Roderick Colenbrander wrote: > As of Wine 1.1.23 wined3d made FBOs the default offscreen rendering > method. If you are using a non-nvidia card (those in general have > buggier drivers) that could explain all the failures. Setting > OffscreenRenderingMethod to backbuffer restores the old behavior. > > Roderick > > On Fri, Jun 5, 2009 at 10:04 PM, chris ahrendt wrote: > >> Something majorly changed and is wrong with the latest GIT tree. >> Between the comits yesterday and today 90% of the tests get exceptions >> or fail. >> All of the d3d tests get a process exception and fail with a dialog box. >> >> >> Ideas? >> >> Chris >> >> >> >> >> >> >> >> >> >> >> > > where do I set that?
Latest Git build 7aeffc442cc1 for Wine 1.1.23
Something majorly changed and is wrong with the latest GIT tree. Between the comits yesterday and today 90% of the tests get exceptions or fail. All of the d3d tests get a process exception and fail with a dialog box. Ideas? Chris
WIne DIB
On 05/30/2009 12:59 PM, wine-devel-requ...@winehq.org wrote: > Ben Klein ha scritto: > >> >> You would be surprised at how much of Wine is NOT a hack internally. >> Wine doesn't do hacks, > > Well, well there are some, indeed. > Of course, it's better not add new ones :-) > > hence AJ's reluctance to include the current >> DIB proposal in Wine (to make it "correct" later will require a lot of >> hacking, as Max has objected). > > Again, my engine isn't a hack. Nor you'll need hacks to embed it on > gdi32. > Even more, some parts will be simplified because of direct access to > internal > gdi32 structures, which can't be done (without hacks) in current > implementation. > The *only* semi-hack is the direct access of gdifont struct from > inside winedib > it could also be avoided, but with much useless code added. > Useless because it will be so once embedded in gdi32. >> >>> Do we even have an architectural document or guidelines to reference? >> >> This was also raised on the existing thread. No. This is a problem. >> The best we have so far is "DIB engine should be integrated into >> GDI32". This is not a problem, because both Max and AJ share this >> goal, but if I understand correctly, Max doesn't want to invest the >> effort (which is a lot) until the current design is validated by >> inclusion into upstream source. > > You got exactly the point :-) > To be precise, the effort isn't so huge, but summed with the effort of > maintaining > all in sync with current tree the global effort would be great (and > dumb, imho). >> >> >> Welcome aboard! I suggest that if you'd like to help out with the DIB >> engine (with the goal of getting it included to Wine upstream source), >> that you take a look at the code on bugzilla page #421 and talk to >> Massimo about how you might adapt it for integration into GDI32. >> > There's not too much to adapt moving the engine inside gdi32 is > (IMHO) > not complicated at all. More a writing effort than a coding one. > But, *before*, I guess winex11.drv (and any possible driver that does > DIBs internally) > should be patched stripping DIB handling *and* adding some stuffs for > mixed transfers. > Again, not an huge work, for somebody that knows well drivers internals. > It could also be done later, if wished... but logically that would be > the first step. > > Ciao > > Max > > Ok Max then document what you think the effort would be and what is needed to migrate your DIB engine into GDI32 Then We could send it to AJ for approval and go from there. This would be documenting the Delta which should allow AJ to go line item by line item and say yes or no to each or what needs to do. How long would that take you to do Max? Once that is done we would have a defined plan etc and going forward it would be documented. Chris
Re: DIB engine
On 05/29/2009 12:28 PM, James Mckenzie wrote: >> As was said in the other thread, just designing it alone would take a >> few months work. AJ is really busy with other things, and a few months >> work is both a lot of money and a lot of wasted productivity. No one >> is stepping up to sponsor the work, so it's a bit hard for him to take >> that on. >> > Who is asking AJ to do all of the work. Huw Davies and Max have worked out > what is needed to get this into Wine. All we need is guidance on what is > acceptable and how we should proceed. This seems to be a serious shortcoming > on AJs part. Without this, any further work would be futile and could end up > being very frustrating. I've seen this from Huw and it is starting to come > from Max. AJ needs to get some time together and write up what is and is not > acceptable as far as code style, fashion and what he expects out of the > development efforts for the DIB engine. Making a statement > after months of work is IHMO very unacceptable. > > Also, I don't see this as circular, but the 'snake' of getting AJ to accept > code into the codebase is. > > Very respectfully submitted, > > James McKenzie > > > > Agreed James, this is the exact point I am getting at I guess... what exactly is acceptable and what is not... It seems we have a working solution for DIB. I do not think that it would take that long for AJ to sit down and say here.. this is what I want or this is what is acceptable then its up to the development people to come back and say ok here is our solution and then rectify the delta's in between. If Huw and Max have a solution then what is the delta? Chris
Re: DIB engine
On 05/29/2009 11:14 AM, Austin English wrote: > On Fri, May 29, 2009 at 10:10 AM, chris ahrendt wrote: > >> Question on this debate: >> >> Has AJ documented anywhere what the architectural issues are so they can >> be addressed? >> I have not seen this in the thread and was just wondering. >> If we have them documented then its a relatively easy task to address >> each of them. >> Yes it may be a hack but you would be surprised at how much of Windows >> is a hack internally. >> >> Do we even have an architectural document or guidelines to reference? >> > If you read the entire thread, you'll see that the DIB design is not a > puzzle that can be carved out and dropped in. The DIB engine must be > designed from scratch. Designing the DIB architecture is half of the > work itself, since that involves planning a lot of the code/testing, > etc. > > He pointed out a few things he didn't like about Massimo's design, but > not a full 'here's the spec, do this exactly'. > > For more details, read the full thread and past discussions. > > -- > -Austin > > > Right Austin, I have... thats why I asked the question why not sit down and say here is what we want from the DIB engine here is the Spec do this .. I have seen the here is what I don't like. But nothing showing what exactly is needed. This would be the first step in resolving this circular argument / discussion which is what I am trying to facilitate =D. Until that is done all we can do is have this same circular argument / discussion =D chris
DIB engine
Question on this debate: Has AJ documented anywhere what the architectural issues are so they can be addressed? I have not seen this in the thread and was just wondering. If we have them documented then its a relatively easy task to address each of them. Yes it may be a hack but you would be surprised at how much of Windows is a hack internally. Do we even have an architectural document or guidelines to reference? Chris
Re: Question on writing a testcase..
Paul Vriens wrote: > chris ahrendt wrote: >> I have two test cases for the file.c test in kernel32 to show two >> problems I have found and reported as bugs that wine should be able >> to handle. >> >> first problem : >> >> I/O warning : failed to load external entity >> "file:///C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml" >> >> Wine does not seem to be parsing this correctly while the various >> windows platforms do correctly. >> So I would like to put a test for this in the test case. >> >> Second file issue I found that needs a test case : >> >> I/O warning : failed to load external entity "EQ/updatestatus.xml" >> >> It seems wine is expecting a fully qualified path in this case where >> as windows uses the application running directory and then looks >> there... >> I am not even sure where this is looking in wine. I would guess at >> the root level from the z: mapping if I had to venture a guess >> instead of the current running directory. >> >> Would I just write the two subroutines and then submit them to >> wine-patch? >> >> Chris >> >> > What function(s) are the tests for? Did you already write some > testcases and run them on Windows? > > -- Cheers, > > Paul. > > They are for the open file api let me find the exact API.. filehandle = _lopen( filename, OF_READ ); in the dlls/kernel32/tests/file.c I also would write the test for _lcreate and the other couple of API's that return a file handle. And I am using an application on windows already that does the open in this manner... but could hack something out really quick. Chris
Question on writing a testcase..
I have two test cases for the file.c test in kernel32 to show two problems I have found and reported as bugs that wine should be able to handle. first problem : I/O warning : failed to load external entity "file:///C%3A/Program%20Files/Sony/Station/LaunchPad/PatchCache2.xml" Wine does not seem to be parsing this correctly while the various windows platforms do correctly. So I would like to put a test for this in the test case. Second file issue I found that needs a test case : I/O warning : failed to load external entity "EQ/updatestatus.xml" It seems wine is expecting a fully qualified path in this case where as windows uses the application running directory and then looks there... I am not even sure where this is looking in wine. I would guess at the root level from the z: mapping if I had to venture a guess instead of the current running directory. Would I just write the two subroutines and then submit them to wine-patch? Chris
Re: wine-devel Digest, Vol 46, Issue 10
wine-devel-requ...@winehq.org wrote: > ___ > wine-devel mailing list - wine-devel@winehq.org > http://www.winehq.org/mailman/listinfo/wine-devel > > > > > Subject: > Re: RFC on Base Wine Config > From: > Kai Blin > Date: > Sun, 3 May 2009 09:04:13 +0200 > To: > wine-devel@winehq.org > > To: > wine-devel@winehq.org > > > On Sunday 03 May 2009 07:07:35 Ben Klein wrote: > >> 2009/5/3 chris ahrendt : >> > > Replying to Ben's email as I didn't get Chris' email Ben replied to. > I would also like to note that I don't appreciate the tone both of these > emails are taking in the end. Please try to be civil. > > That being said, let me get to the technical part. > > >>> I guess I am not being completely clear somewhat >>> If I am in windows and go into explorer... >>> >> We've been through this before. Wine is not Windows. In Wine, the >> drive has to be mapped in dosdevices. >> >>> go to a network drive. I do >>> not nescisarily have to map that drive in order to run an application >>> (so long as the DLLS it needs, if any, are not just on that drive). I >>> can click the application >>> and it runs. I realise this may be a fundamental difference between unix >>> and windows but still they should theoretically run the same. >>> > > The important part here is that your local drives are local drives. Don't > confuse the Wine drive mappings with network drive mappings in Windows. Think > about a Wine drive mapping like plugging a new hdd into your box. > > >> But you're NOT running the test from a network drive, are you? And >> even if you were, you'd need some way to inform Wine that it's there, >> which would be to map it to a drive. Does Wine even support >> Windows-style shares? >> > > Nope. We could, but then you'd have to create a Samba share to allow us to > use > the directory. I'm pretty sure a wine drive mapping is easier and faster. > > >>> Also from >>> a command line I can do (I think if I am remembering correctly (been >>> doing to much z work lately) ) //server/directory/app.exe and it will >>> retrieve and run the app... (I think) >>> > > That's a bit besides the point, as this is still a valid UNC path. Now > imagine > I've got a USB hdd with my app on it, and that's usually connected at U:, > with my app being at U:\test\app.exe. Now the logic in Windows mapping my USB > drive to U: is just what the wine dosdevice mapping is like. If I now tell > windows to remove the USB device, my desktop link to U:\test\app.exe is not > going to work anymore. > > >> This message appears in your bug report: >> >>> Warning: could not find DOS drive for current working directory >>> '/home/cahrendt/wine-git/dlls/inetmib1/tests', starting in the Windows >>> directory. >>> > > Here my analogy would be a bit stretched, as in that you'd still manage to be > on the USB drive while it's already been disconnected. But basically you're > trying to run a program that's on a drive not connected to your wine "box". > > Cheers, > Kai > > > Thanks Kai, This is the kind of dialog I was looking for in the RFC. This makes sense. In a way with you are in a seperate 'region' and do not have access to that regions resources unless you map it. Even though wine is not a emulator it is essentially a VM running in userspace on the box that you need to allocate some resources to. (not so much like solaris 10 or zVM's where you can set up resources for everything). Ok clear now. Chris
Re: RFC on Base Wine Config
Juan Lang wrote: >> ok then I am very confused then... >> I deleted the / mapping all together and then ran the dotest script and >> the make test scripts >> dotest fails if the / mapping is not there along with the inetmib1 >> test. I opened a bug >> concerning the inetmib test failing and was told that my configuration >> with the / mapping deleted >> was an invalid wine configuration that the / is absolutely needed by wine. >> >> So I am confused... is it required or not? >> > > It is not required. What _is_ required is that the path to the > current executable is mapped, somewhere. I suggested you remap Z: to > / as it's the default, and it was the most concise way to ensure that > your configuration met the requirement. As Ben said, you could map > any drive. Heck, you could have mapped Q: to the dlls/inetmib1/tests > directory and the inetmib1 test would have worked, while having no > mapping would not work. > --Juan > > > I realise this juan... I guess I am not being completely clear somewhat If I am in windows and go into explorer... go to a network drive. I do not nescisarily have to map that drive in order to run an application (so long as the DLLS it needs, if any, are not just on that drive). I can click the application and it runs. I realise this may be a fundamental difference between unix and windows but still they should theoretically run the same. Also from a command line I can do (I think if I am remembering correctly (been doing to much z work lately) ) //server/directory/app.exe and it will retrieve and run the app... (I think) Chris
Re: RFC on Base Wine Config
Ben Klein wrote: > 2009/5/3 chris ahrendt : > >> I have noticed something with reporting bugs and problems that are >> encountered... >> >> If the user is allowed to delete the Z: share to / once this is done >> things start acting strange or not working. >> > > In general, you can't run apps outside of what's linked to in > dosdevices. You certainly can't launch them from inside Wine. The link > to / is mostly there for convenience so you don't have to keep dumping > downloads (e.g. patches or small installers) in ~/.wine/drive_c every > time you want to install them, and partly to allow Wine to launch > applications in /usr/bin et al (e.g. winebrowser). > > >> Many people have done this for various reasons. >> > > Yes, and it's valid to do so. > > >> My suggestion is to do the following: >> >> 1. If we have a base configuration that should not change for settings >> IE the Z: mapping then do not allow this to be changed or deleted in >> winecfg. If someone is dumb enough to go into the ini file and delete it >> then they should know better. >> > > This would make a lot of people unhappy (like the creation of the > Universe) for "various reasons". > > >> 2. If it is critical that the Z: or drive mapping be there for / then >> if its missing should wine then handle this condition? >> > > 1) It's not critical. > 2) Wine already handles this condition. It's no different from any > other drive link in this way. It doesn't even have to be Z; you can > manually change it to be D if you really want. The only critical drive > is C: and that IS handled differently (especially in winecfg). > > > ok then I am very confused then... I deleted the / mapping all together and then ran the dotest script and the make test scripts dotest fails if the / mapping is not there along with the inetmib1 test. I opened a bug concerning the inetmib test failing and was told that my configuration with the / mapping deleted was an invalid wine configuration that the / is absolutely needed by wine. So I am confused... is it required or not? and if it is then we get back to my original RFC here =D Chris
RFC on Base Wine Config
I have noticed something with reporting bugs and problems that are encountered... If the user is allowed to delete the Z: share to / once this is done things start acting strange or not working. Many people have done this for various reasons. My suggestion is to do the following: 1. If we have a base configuration that should not change for settings IE the Z: mapping then do not allow this to be changed or deleted in winecfg. If someone is dumb enough to go into the ini file and delete it then they should know better. 2. If it is critical that the Z: or drive mapping be there for / then if its missing should wine then handle this condition? Chris
Re: Dan's dotest reports
André Hentschel wrote: > chris ahrendt schrieb: >> Are the Wine Developers using this report? >> >> Chris >> >> >> >> >> >> >> >> >> > If you are talking about the testsuite(test.winehq.org) then it is not > the only source of information for developers but an important one. > > yes that is what I am talking about... just wanted to make sure that by running the tests on linux the results get used...
Dan's dotest reports
Are the Wine Developers using this report? Chris
Re: do ERR messages imply bugs?
Ben Klein wrote: 2009/4/13 chris ahrendt : Is there a guide documenting what each test is supposed to do etc? Source code. Before you say that's an unacceptable answer, the sheer number of test cases (especially considering those that keep getting added) would make it impractical to the point of impossibility to maintain proper documentation on each test. And when the tests are only intended for developers anyway, the source code is perfectly suitable as documentation. The tests are relatively simple, and it's clear which case is being test by the use of ok(). I run the test set to see where the current version of wine is on any of my particular hardware. Then you should learn to interpret the ERRs correctly. I am not allowed to develop wine due to NDA's , and so forth I am under. And have discussed with the Alexandre and Dan concerning these NDA's and what I can do to help. That does not make any sense... There has to be a consistent way for developers and users to report or work on issues.. It's called bugzilla. I believe you may be missing my point Ben. By consistent I mean an ERR means this and only means this. Warning, info etc... As far as I'm concerned, that already exists, even if it's not written explicitly and finitely in the dev guide. ERRs caused by the test suite can be ignored as long as the tests run correctly. By the same logic, ERRs caused by real applications can be ignored as long as the apps still run correctly. In the former case, there is no motivation for the devs to fix them. In the latter, there is minimal motivation, and the devs have bigger problems to worry about than things that aren't actually *breaking* anything at the moment. From what I have been following here and also seeing in the code an error doesn't always follow the coding standard set forth in the developers guide. I don't think you understand the nature of the test suite. There are some tests that are 100% valid logic and are expected to create no ERRs or WARNs. These are called positive cases. There are some tests that are not 100% valid logic, and do things wrong deliberately, and are expected to create both ERRs and WARNs. That's an "and" there, not an "or". Both ERRs and WARNs. This cannot change. and like Vincent says the use has gotten a little skewed. Or been misinterpreted ... though a review of the developers' guide description of ERR wouldn't hurt. I would agree it may be... and maybe a review is in order.. So who wants to volunteer? :) Not I =) 2009/4/13 chris ahrendt : An Excellent point was mad in one of the bugs I reported : Comment #25 from Austin English The problem is that this isn't a 'normal' application doing weird things. It's our testsuite, which does some _really_ strange stuff, e.g., lots of corner case testing. Our implementation code, however, knows this is weird, and prints an error. The problem is that there's no way to tell, e.g, dlls/mshtml/htmldoc.c that what's being tested is dlls/mshtml/tests/doc.c, rather than foobar.exe. It's a bit misleading, which makes it a bit harder for users. This is EXACTLY what I've been saying. You ignore me, and listen to Austin. Absolutely fantastic. not AT All ben =D I do and have understood that there are positive and negative test cases. The point I guess I am trying to make is in the test cases where there is an expected failure just print something out saying this is expected. Not Complicated at all. So, there has to be a happy middle in this... why not have in the test suite some printf or the like that says to the effect that err output is to be expected or the like.. Most users if they see ERROR on the screen be it in a test case or an application will think its a bug and not just ignore it. Most users DON'T RUN THE TEST SUITE. It's not useful for users, it's ONLY useful for developers, and developers know how to interpret these ERRs correctly. You don't. Thanks for the attack ben... again you miss the point.. alot more users do run the tests than you may think. People evaluating the code for use in their enterprise will run the test sets.. and if they don't complete or run clean than they don't implement. C
Re: do ERR messages imply bugs?
An Excellent point was mad in one of the bugs I reported : Comment #25 from Austin English The problem is that this isn't a 'normal' application doing weird things. It's our testsuite, which does some _really_ strange stuff, e.g., lots of corner case testing. Our implementation code, however, knows this is weird, and prints an error. The problem is that there's no way to tell, e.g, dlls/mshtml/htmldoc.c that what's being tested is dlls/mshtml/tests/doc.c, rather than foobar.exe. It's a bit misleading, which makes it a bit harder for users. So, there has to be a happy middle in this... why not have in the test suite some printf or the like that says to the effect that err output is to be expected or the like.. Most users if they see ERROR on the screen be it in a test case or an application will think its a bug and not just ignore it. Chris
Re: do ERR messages imply bugs?
Ben Klein wrote: 2009/4/13 chris ahrendt : So basically it, in your opinion, comes down to ERR's and the debug output from running tests or anything else should be ignored by anyone but developers? No, that the tests as a WHOLE should be ignored by everyone except developers. Is there a guide documenting what each test is supposed to do etc? I run the test set to see where the current version of wine is on any of my particular hardware. I am not allowed to develop wine due to NDA's , and so forth I am under. And have discussed with the Alexandre and Dan concerning these NDA's and what I can do to help. That does not make any sense... There has to be a consistent way for developers and users to report or work on issues.. It's called bugzilla. I believe you may be missing my point Ben. By consistent I mean an ERR means this and only means this. Warning, info etc... From what I have been following here and also seeing in the code an error doesn't always follow the coding standard set forth in the developers guide. and like Vincent says the use has gotten a little skewed. Or been misinterpreted ... though a review of the developers' guide description of ERR wouldn't hurt. I would agree it may be... and maybe a review is in order.. chris
Re: do ERR messages imply bugs?
Ben Klein wrote: 2009/4/13 James McKenzie : Ben Klein wrote: 2009/4/13 chris ahrendt : Vincent Povirk wrote: On Sun, Apr 12, 2009 at 5:24 PM, Ben Klein wrote: 2009/4/13 Vincent Povirk : But the description doesn't say "invalid conditions". It says "serious errors in Wine". That's something that should never happen in tests, as it would imply that the state of the libraries we're testing (and thus the test) is invalid. How about "serious errors in Wine, or in the test cases, sometimes deliberate errors in the tests"? As Vitaliy points out, some tests deliberately do invalid things to make sure they fail. We can't ONLY test on things that succeed! I'm not against changing the description. If it's OK to have err messages for cases that we know fail (but don't crash or prevent the library from continuing to function), then the Developer's Guide is wrong and should be changed. I also don't care how long it takes to make the change, as long as there's a consensus that it's the guide that's wrong and not the reality of what's in Wine. This is EXACTLY the point I am trying to get to.. if they are normal and not ERRORS but warnings then they should be thus and noted in the developers guide. Right now Wine isn't even following its own guidelines in this case. No. Not warnings. Errors. They are errors. There is no way to distinguish an error caused by a real application from an error caused by a Wine test. If the situation is an error and it is expected, the test should handle this, like: ok (some_test_here_that_should_fail, "The test that should fail, did/n") I'm guessing that most of the tests that should fail, do. I don't know if there is a failure like there is an ok. AFAIK, this is how expected failures in tests are handled. I saw a few recent tests submitted and/or committed that do it like this. If you don't like it, run all your tests with WINEDEBUG=-all. And that will prove nothing. Tests should be run with debugging on. You are really being sarcastic, right? As to the discussion, I will add my .02 Eurocent here: Fixme: Code that is not implemented that should be. Warning: Code that encountered an unexpected or new condition that is not normal. Data should not be corrupted by this event. Error: Code encountered a condition that will result in corruption of data. It appears that we have 'error creep' and that is not good from a user point of view and it is really irritating from a support point of view. During testing an error could be either a Warning or an Error. Tests should not be run against non-existent Wine code, but should against existing Windows code. The situation with testing is that unexpected or improper behavior of code should be an error. There is no such thing as a warning during a test run. Either the test passes, which means that Wine is acting the same as a certain version of Windows, or it is not. There is no way for the Wine components that are producing the errors to distinguish between a test run and a real application. Again, the tests are triggering these errors not in the test applications but in other Wine components. In some (possibly all) cases that this happens, this is expected and correct (because it is impossible to distinguish between a genuine error and a test error). Now, the problem is that we are sending cryptic messages to end users, most of which they can and should ignore. Err messages piling up on their terminal windows should be a cause for concern. If we know that a condition does not cause data corruption, then we should not be marking it as an error, but maybe a warning or if the code is non-existent or improper, a fixme. End users shouldn't be running the tests without understanding how they work. Can we start to clean up some of the most obvious "it is not an error but the message says it is" so that we can calm down users who encounter them? The ERRs are being produced by components of Wine outside the test cases. It's highly likely for those ERRs to change in later versions of Wine. If you want to maintain a complete list of where ERRs will be triggered by test cases and include a message for each one that says "It's OK, you can ignore this ERR", then I'm sure you're welcome to try it. 2009/4/13 James McKenzie : Vitaliy Margolen wrote: You wrong. As I said, tests are _allowed_ and some really _supposed to_ test invalid cases. Where Wine 100% correct about complaining. But the goal of each test is either succeed or fail. If it succeeds then there is no bug. Conversely, if a good test starts to fail or error messages appear where there were none, we have a problem that
Re: do ERR messages imply bugs?
Vincent Povirk wrote: On Sun, Apr 12, 2009 at 5:24 PM, Ben Klein wrote: 2009/4/13 Vincent Povirk : But the description doesn't say "invalid conditions". It says "serious errors in Wine". That's something that should never happen in tests, as it would imply that the state of the libraries we're testing (and thus the test) is invalid. How about "serious errors in Wine, or in the test cases, sometimes deliberate errors in the tests"? As Vitaliy points out, some tests deliberately do invalid things to make sure they fail. We can't ONLY test on things that succeed! I'm not against changing the description. If it's OK to have err messages for cases that we know fail (but don't crash or prevent the library from continuing to function), then the Developer's Guide is wrong and should be changed. I also don't care how long it takes to make the change, as long as there's a consensus that it's the guide that's wrong and not the reality of what's in Wine. This is EXACTLY the point I am trying to get to.. if they are normal and not ERRORS but warnings then they should be thus and noted in the developers guide. Right now Wine isn't even following its own guidelines in this case. Chris
Re: do ERR messages imply bugs?
Vitaliy Margolen wrote: chris ahrendt wrote: 17997 Gecko is installed and reran test... same result... valid bug 17998 is the locking issue... and it occurs not just in the rest but in another application as well.. What errors? What exactly isn't working for you? You have failed to explain that. Until you meaningfully can explain everyone what isn't working for you? What exact applications are you having problems with? Where are they failed tests you are speaking of, these bugs invalid! DO NOT REOPEN THEM! Vitaliy. THe ERR mesages which are in the logs I uloaded. As pointed out in the wine development logs an ERR is only supposed to happen if something goes wrong or is not working correctly. So either these are warning messages and need to be changed as such or they are actual failures in the underlying code and will need to get fixed. If the action is normal for the failure in the test case then it should be output on the screen somewhere in the log stating this is normal. Chris
Re: do ERR messages imply bugs?
Vitaliy Margolen wrote: Vincent Povirk wrote: Chris Ahrendt filed a few bugs recently for "err" messages encountered during test runs (17997 and 17998 at least). 17997 is a bogus report - Gecko is not intalled. Nothing actually failed. 17998 is the same. Only I let our resident 3D gurus to respond. I don't see any problems with tests testing invalid conditions. This most likely one of those cases. If Chris doesn't like err messages, he can shut them off. Vitaliy. 17997 Gecko is installed and reran test... same result... valid bug 17998 is the locking issue... and it occurs not just in the rest but in another application as well..
Re: do ERR messages imply bugs?
Vincent Povirk wrote: On Sat, Apr 11, 2009 at 11:49 PM, chris ahrendt wrote: So in the case of the multiple locks and err's the output of the test run is the same for bug 7284 <http://bugs.winehq.org/show_bug.cgi?id=7284> then this bug or output would be invalid as well? The bug description claims it's about lighting effects, not err messages. Also, the test log (whose relevance to the bug I do not understand) shows actual failures. the log on that bug also shows the failure I mentioned as well chris
Re: do ERR messages imply bugs?
Ben Klein wrote: 2009/4/12 Vincent Povirk : Chris Ahrendt filed a few bugs recently for "err" messages encountered during test runs (17997 and 17998 at least). Vitaliy claims they are invalid. 17997 looks invalid due to missing Wine Gecko. 17998 looks like uncleanliness in the test to me (trying multiple times to lock a surface that's already locked). Perhaps this is the point of this particular test, trying to determine if Wine will crash if the lock is attempted multiple times? I really can't say, but no programmatic errors have been reported in either case. In both it's "Wine gives an err message on stderr", but no loss of functionality is reported. If they can be fixed without changing the *intent* of the code (17998 in particular), then it's my opinion that they are valid as enhancements (which is what the severity is set to). In order to explain clearly why they are invalid, I looked up the official definition of ERR in the Wine Developer's Guide: "Messages in this class indicate serious errors in Wine, such as as conditions that should never happen by design." (http://www.winehq.org/docs/winedev-guide/debugging) This goes against my preconceived notion. Bad developer's guide, bad. To my even greater astonishment, all the ERR messages I've added fit this description. Bad past self, bad. I'd say an ERR indicates a potential and/or serious loss of functionality for a program you're running in Wine. I'm pretty sure that in some cases, ERRs will be triggered in Wine even when that particular thing doesn't work in Windows. The consensus (or so I thought) seems to be that ERR messages are simply for debugging and can safely be ignored as long as nothing is going wrong in a running program (in this case, as long as the tests are not failing). This is certainly true for FIXMEs (which are by definition known bugs, and in fact can cause loss of functionality in some cases). In the case of ERRs, if the program runs fine, then all is well :) It's just that it's much more likely for an ERR to be associated with a broken program or loss of functionality. "Serious errors" sounds like something that should be worth investigating, even without visible failures. How do we resolve this discrepancy? Probably by disagreeing with everything I've said :P So in the case of the multiple locks and err's the output of the test run is the same for bug 7284 <http://bugs.winehq.org/show_bug.cgi?id=7284> then this bug or output would be invalid as well? C
Re: RFC: Proposed new web site design
Austin English wrote: > On Tue, Nov 25, 2008 at 12:27 AM, Scott Ritchie <[EMAIL PROTECTED]> wrote: > >> We also don't really need a link to AppDB from the big buttons in the >> front - AppDB is only the place to go when you're looking for it (hence >> the button in the upper right) or once you know something about Wine >> (hence a link in the about page). >> >> > > I disagree. You could make the same argument against > bugzilla/forums/wiki. The frontpage should serve as a portal to the > rest of the site. Many times when I needs appdb/wiki, I go to > winehq.org and then click the appropriate link. > > I agree the main page should be the portal where you go to find everything... chris p.s. kudo's on the new design!
Re: Try#4 for IDirectDrawSurface_GetSurfaceDesc error checking in ddraw test
Stefan D
Try#4 for IDirectDrawSurface_GetSurfaceDesc error checking in ddraw test
Michael / All, Been busy for awhile so have not had the time to work on this patch but here is the 4th try and hopefully final version of the ddraw patch. I took Michaels suggestions and encorporated them into the patch as well. Please let me know if this patch is now ready to submit =) chris 0001-This-is-the-Fix-for-an-exception-which-occurs-in-dsurf.txt Description: Binary data
Re: [ddraw/tests] Fix a test on W2K3
Paul Vriens wrote: > Henri Verbeet wrote: > >> 2008/11/4 Paul Vriens <[EMAIL PROTECTED]>: >> >>> Hi, >>> >>> I upgraded to VMware 6.5.0 this morning and overlay tests are run now on my >>> W2K3 >>> box. As the return value indicates E_NOTIMPL I decided to add a skip() for >>> one particular test. >>> >>> >> VMware is not a valid test platform for ddraw. >> >> >> >> > And how would you like to approach that? Most of us run tests on some piece > of > virtualization software. Should we check for VMware and don't run d3d8/9/10 > and > ddraw tests anymore at all? We do want to have a green test.winehq.org after > all. > > I agree that we shouldn't use VMware as a valid test platform for ddraw but > as > long as the skips are kept to a minimum can't we live with that? > > (What would have happened with the patch when I wouldn't have mentioned > VMware?) > > Actually as of 6.5 of VMWARE direct draw 9c is 100% supported. So why couldn't we use vmware 6.5 as a valid platform for testing direct draw api's? chris
make test solution
NM figured it out... some odd reason the git directory has to be mapped to a windows drive.. once I did that.. it all cleaned up... chris
make test issue..
I have a general question on the make files... specifically the make test portion of it.. Since talking to dan about things this would be where I could be of most help. I have an issue with the make test currently.. I am getting : [EMAIL PROTECTED] wine-git]$ make test make[1]: Entering directory `/home/cahrendt/wine-git/tools' make[1]: `makedep' is up to date. make[1]: Leaving directory `/home/cahrendt/wine-git/tools' make[1]: Entering directory `/home/cahrendt/wine-git/dlls' make[2]: Entering directory `/home/cahrendt/wine-git/dlls/advapi32/tests' ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so cred.c && touch cred.ok Warning: could not find DOS drive for current working directory '/home/cahrendt/wine-git/dlls/advapi32/tests', starting in the Windows directory. wine: could not load L"C:\\windows\\system32\\advapi32_test.exe.so": Module not found make[2]: *** [cred.ok] Error 126 make[2]: Leaving directory `/home/cahrendt/wine-git/dlls/advapi32/tests' make[1]: *** [advapi32/tests/__test__] Error 2 make[1]: Leaving directory `/home/cahrendt/wine-git/dlls' make: *** [dlls/__test__] Error 2 which is not a code issue as far as I am able to see but rather a make file issue. As you see the advapi32 test can't be found. However if you look in the directory the .so is there... so I need some assistance to help me understand where and how the make test works so I can figure out why its looking in the system32 directory and not the current directory for the shared object. Any help? Chris
Re: latest GIT
Austin English wrote: > On Sun, Oct 19, 2008 at 9:15 PM, chris ahrendt <[EMAIL PROTECTED]> wrote: > >> Anyone else having a problem compiling the latest git? >> >> mine has failed 2 times when I compile... one with a clean tree and one >> with an older tree.. >> >> chris >> >> >> >> __ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> >> >> >> > > What error are you getting? What gcc version? > > so has anyone figured out why its broken yet? chris __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: latest GIT
Austin English wrote: > On Sun, Oct 19, 2008 at 9:15 PM, chris ahrendt <[EMAIL PROTECTED]> wrote: > >> Anyone else having a problem compiling the latest git? >> >> mine has failed 2 times when I compile... one with a clean tree and one >> with an older tree.. >> >> chris >> >> >> >> __ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> >> >> >> > > What error are you getting? What gcc version? > > make[2]: Entering directory `/home/cahrendt/wine-git/tools/widl' gcc -c -I. -I. -I../../include -I../../include-Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o parser.yy.o parser.yy.c parser.l: In function ‘xstrtoul’: parser.l:92: error: ‘errno’ undeclared (first use in this function) parser.l:92: error: (Each undeclared identifier is reported only once parser.l:92: error: for each function it appears in.) parser.l:94: error: ‘ERANGE’ undeclared (first use in this function) make[2]: *** [parser.yy.o] Error 1 make[2]: Leaving directory `/home/cahrendt/wine-git/tools/widl' make[1]: *** [widl] Error 2 make[1]: Leaving directory `/home/cahrendt/wine-git/tools' make: *** [tools] Error 2 GCC version 4.1.2-45.el5 chris __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
latest GIT
Anyone else having a problem compiling the latest git? mine has failed 2 times when I compile... one with a clean tree and one with an older tree.. chris __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Splitting the appdb Top 25 list
MY $.02 cp on the issue agrees with the others... I would say split it up.. but more possibly than applications and games.. Say : games Utils Development Tools Applications Chris __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Try #3 for IDirectDrawSurface_GetSurfaceDesc error checking in ddraw test
Michael / All here is the third go at the ddraw test... and the patch for that... note I went ahead and used the goto. Also I found an error in the test where it was allocating the buffer in one place and it did not free it. Now here is the curious thing... When I did the first run of the ddraw test I got the output found in the no_ulimit_run attachment which did not seem right as nothing ran or didnt seem to. So I did the ulimit -s unlimited and then re-ran the test and got the second output... Now shouldn't the test run the same reguardless of the stack limit? Chris 0001-Fix-for-dsurface-for-IDirectDrawSurface_Release-error.txt Description: Binary data no_ulimit_run Description: Binary data ulimit_unlimited_run Description: Binary data
Re: Try #2 IDirectDraw_CreateSurface Failure on WINE test in dsurface.c code
Michael Karcher wrote: > I put the list back on CC because someone there might know about the > drmMap problem. > > Am Dienstag, den 14.10.2008, 15:30 -0700 schrieb chris ahrendt: > >>> PS: From the attachments of Chris' mail, one can get the following >>> information: The environment we are currently talking about is Wine on >>> Linux, an ATI FireGL 5200 graphics board driven by the closed source >>> driver, and somehow broken DRM. >>> >> >> Broken DRM? >> > Yes. This shouldn't appear in your log if DRM is working: > | libGL error: drmMap of framebuffer failed (Cannot allocate memory) > | libGL error: reverting to (slow) indirect rendering > > This might be caused by wine blocking the address space used for kernel > addresses in real windows, or it might be a misconfiguration or > installation problem of the ATI driver. Cross-checking with glxgears is > recommended. > > But even if non-functional DRM causes CreateSurface to fail you are > right that the testcase should handle that. > > Regards, > Michael Karcher > > > > > This used to be fixed like I said by doing the ulimit -s unlimited trick but now since drop 15 even that has stopped working. I did a little checking and there seems to be another way to get this error where the focus is lost for the X session. I just added this other fix as well : |Section "DRI" Group "video" Mode0666 EndSection| | | Ati has a bug reported on this : 737-35215: Creating two successive connections my result in Direct GL context to fail here is a code fix that is supposed to work: The following (psuedocode) sequence, forces fglrx to revert to indirect rendering: dpy = XOpenDisplay() visual = glXChooseVisual(dpy) XCloseDisplay(dpy) ... dpy2 = XOpenDisplay() ctx = glXCreateContext(dpy2, visual) <-- fglrx reverts to indirect rendering ... Changing the code to use the same display connection for glXChooseVisual Chris and glXCreateContext solves this problem.
Re: Try #2 IDirectDraw_CreateSurface Failure on WINE test in dsurface.c code
Michael Karcher wrote: > I put the list back on CC because someone there might know about the > drmMap problem. > > Am Dienstag, den 14.10.2008, 15:30 -0700 schrieb chris ahrendt: > >>> PS: From the attachments of Chris' mail, one can get the following >>> information: The environment we are currently talking about is Wine on >>> Linux, an ATI FireGL 5200 graphics board driven by the closed source >>> driver, and somehow broken DRM. >>> >> >> Broken DRM? >> > Yes. This shouldn't appear in your log if DRM is working: > | libGL error: drmMap of framebuffer failed (Cannot allocate memory) > | libGL error: reverting to (slow) indirect rendering > > This might be caused by wine blocking the address space used for kernel > addresses in real windows, or it might be a misconfiguration or > installation problem of the ATI driver. Cross-checking with glxgears is > recommended. > > But even if non-functional DRM causes CreateSurface to fail you are > right that the testcase should handle that. > > Regards, > Michael Karcher > > > > > Actually... I was told is because of the ATI driver issue with wine glxgears works just fine... I used to be able to get rid of the libGL errors by doing ulimit -s unlimited but since 15 drop even this has not worked... Chris
Re: Try #2 IDirectDraw_CreateSurface Failure on WINE test in dsurface.c code
Yes if we need to move this off list please let me know
Michael Karcher wrote:
> That's why I suggested you to introduce the err2 label. The end of the
> function should look like this:
>
Ya, Ich versteh
here is the first patch to fix exception 1. I did have the patch with
the skip but decided to try this:
if (surface4)IDirectDrawSurface_Release(surface4);
if (surface3) IDirectDrawSurface_Release(surface3);
if (surface2) IDirectDrawSurface_Release(surface2);
if (surface1) IDirectDrawSurface_Release(surface1);
If I do the above I get the same exception on : if (surface3)
IDirectDrawSurface_Release(surface3);
So to fix that exception I have to do the following:
if (FAILED(hr)) {
skip("failed to create surface3\n");
if (surface2) IDirectDrawSurface_Release(surface2);
if (surface1) IDirectDrawSurface_Release(surface1);
return;
}
This is for IDirectDraw_CreateSurface failure which was not caught
before for 3. The following is for the 4th surface :
if (FAILED(hr)) {
skip("failed to create surface4\n");
if (surface2) IDirectDrawSurface_Release(surface3);
if (surface2) IDirectDrawSurface_Release(surface2);
if (surface1) IDirectDrawSurface_Release(surface1);
return;
}
Next Exception # 2 is caused by lines at 1138 :
hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface1, NULL);
ok(hr==DD_OK,"CreateSurface returned: %x\n",hr);
To Fix that exception I have to add the below.
if (FAILED(hr)) {
skip("failed to create surface1\n");
return;
}
After that exception I have to close the window and reopen a new one to
continue. make test refuses to run or acts strange..
So I figured the env. got hosed by the last exception.
Clean up the ok files and .o and shared object and run make test.
The run 3 is the final output.
The two .ok files contain nothing.
Chris
hardware
Description: Binary data
exception_2_with_first_set_of_fixes
Description: Binary data
run_3
Description: Binary data
exception_1_no_fixes
Description: Binary data
Re: Try #2
Michael Karcher wrote:
> Am Montag, den 13.10.2008, 21:05 -0400 schrieb Chris Ahrendt:
>
>> Fixed a trailing space error..
>>
> Sorry to chime in so late on this patchset.
>
> First, some general remarks: The subject of your mail will be the
> one-line commit message. "Try #2" is not a good choice for that. Also it
> does not have enough context for the casual wine-patches reader, as the
> message overview does not show what you patch is about. The usual
> convention is to take the subject of the first try, and append (or
> prepend) "(try 2)" to that subject.
>
>
>> Subject: [PATCH] Pared Down Test For ddraw test... fixes error with
>> IDirectDraw_CreateSurface
>> where the test is not checking the return from the call. CreateSurface is
>> returning a null.
>>
> Another convention is to *not* use the [PATCH] tag on wine-patches, as
> all mails on wine-patches are patches. Use "--keep-subject" with
> git-format-patch to prevent it.
> Last, but not least, your original subject was way too long. Subjects on
> wine-patches usually mention the component to be patched (that is
> usually the directory name without dlls or programs in front) followed
> by a short synopsis (around 40 to 60 characters, if possible). I suggest
> the following subject for your next try:
>
> Subject: ddraw/tests: Catch failures of CreateSurface to prevent crash
>
> I don't remember whether you had the crash on Windows or on Wine. You
> could put that info also into the subject. As it is more important what
> the goal of your patch is than how you achieve that, something like this
> might also be OK:
>
> Subject: ddraw/tests: Don't crash on Windows with GeForce 4399, driver 42.23
>
> (this subject using made-up numbers on purpose, please fit in your own,
> and only use this line if the crash *is* on native Windows)
>
>
>
>> diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c
>> index fc7bb88..21e6b15 100644
>> --- a/dlls/ddraw/tests/dsurface.c
>> +++ b/dlls/ddraw/tests/dsurface.c
>> @@ -1181,7 +1181,10 @@ static void AttachmentTest7(void)
>> ddsd.dwHeight = GetSystemMetrics(SM_CYSCREEN);
>> hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface3, NULL);
>> ok(hr==DD_OK,"CreateSurface returned: %x\n",hr);
>> -
>> +if (FAILED(hr)) {
>> + skip("failed to create surface3\n");
>> + return;
>> +}
>> /* This one has a different size */
>> memset(&ddsd, 0, sizeof(ddsd));
>> ddsd.dwSize = sizeof(ddsd);
>>
> return inside a test function is bad style. You may use it for try&crash
> debugging, but I don't see any chance to get such a patch committed. In
> this case, you leak one IDirectDraw7 interface, forget to restore the
> cooperative level and you leak two surfaces. The "goto err:" approach is
> preferred if a lot of cleanup is needed (like here). You either want to
> make a label "err2:" before the IDirectDrawSurface7_Release(surface2)
> and use that label (analogous for "err3:" one line before that) or use
> the technique of setting released or uninitialized interface pointers to
> NULL and NULL-Check before calling release.
>
> Same remarks for the next 3 hunks (not quoted).
>
Thing is the two surfaces have not been allocated yet.. they are off the local
stack and just set to null.
>
>> @@ -2208,6 +2220,12 @@ static void SizeTest(void)
>> desc.dwWidth = 128; /* Keep them set to check what happens */
>> ret = IDirectDraw_CreateSurface(lpDD, &desc, &dsurface, NULL);
>> ok(ret == DD_OK, "Creating a primary surface without width and height
>> info returned %08x\n", ret);
>> +/* This should be handled but CreateSurface is failing */
>> +if (FAILED(ret))
>> +{
>> +skip("Can't create cubemap surface\n");
>> +return;
>> +}
>> if(dsurface)
>> {
>> ret = IDirectDrawSurface_GetSurfaceDesc(dsurface, &desc);
>>
> The skip message is wrong. It's not about cubemap at all. Also, this
> hunk is unneeded. If CreateSurface fails, dsurface is unmodified or set
> to NULL (or CreateSurface really badly needs fixing!). As dsurface is
> NULL on the call to CreateSurface, it is null if CreateSurface failed.
> So the condition of the if statement following the CreateSurface call is
> false, and no crash can happen on that NULL pointer.
>
>
>
Yes I just caught this message thanks I will fix that... The
problem here which makes no se
Re: Fix to exceptions in ddtest
---
ok(rc==DDERR_INVALIDPARAMS,"CreateSurface returned: %x\n",rc);
-
+if (FAILED(rc)) {
+ skip("failed to create surface\n");
+ return;
+ }
here it is _expected_ that the surface creation fails. So this code is not
useful. ALso in other places.
ciao, Marcus
Ok that I can fix easy enough...
chris
Ok I fixed the code to take this out... however : one section there is
something I am not sure of so I left it in to prevent the exception from
occuring.
here is my change that doesn't cause an exception:
ZeroMemory(&desc, sizeof(desc));
desc.dwSize = sizeof(desc);
desc.dwFlags = DDSD_CAPS;
desc.ddsCaps.dwCaps |= DDSCAPS_PRIMARYSURFACE;
desc.dwHeight = 128; /* Keep them set to check what happens */
desc.dwWidth = 128; /* Keep them set to check what happens */
ret = IDirectDraw_CreateSurface(lpDD, &desc, &dsurface, NULL);
ok(ret == DD_OK, "Creating a primary surface without width and
height info returned %08x\n", ret);
>> /* This should be handled but CreateSurface is not returning right */
>>if (FAILED(ret))
>>{
>>skip("Can't create cubemap surface\n");
>>return;
>>}
if(dsurface)
{
ret = IDirectDrawSurface_GetSurfaceDesc(dsurface, &desc);
ok(ret == DD_OK, "GetSurfaceDesc returned %x\n", ret);
If those lines are not there then when it gets to the
ret = IDirectDrawSurface_GetSurfaceDesc(dsurface, &desc);
line it throws and exception because dsurface is null.. so
I am wondering if the if should be if(&dsurface) instead of the above?
Chris
>From 6efc80d39533cd5940265b752442f607941fbab9 Mon Sep 17 00:00:00 2001
From: Chris Ahrendt <[EMAIL PROTECTED]>
Date: Mon, 13 Oct 2008 14:23:30 -0400
Subject: [PATCH] Pared Down Test For ddraw test... fixes error with
IDirectDraw_CreateSurface
where the test is not checking the return from the call. CreateSurface is
returning a null.
---
dlls/ddraw/tests/dsurface.c | 28 +++-
1 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c
index fc7bb88..21e6b15 100644
--- a/dlls/ddraw/tests/dsurface.c
+++ b/dlls/ddraw/tests/dsurface.c
@@ -1181,7 +1181,10 @@ static void AttachmentTest7(void)
ddsd.dwHeight = GetSystemMetrics(SM_CYSCREEN);
hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface3, NULL);
ok(hr==DD_OK,"CreateSurface returned: %x\n",hr);
-
+if (FAILED(hr)) {
+ skip("failed to create surface3\n");
+ return;
+}
/* This one has a different size */
memset(&ddsd, 0, sizeof(ddsd));
ddsd.dwSize = sizeof(ddsd);
@@ -1191,7 +1194,10 @@ static void AttachmentTest7(void)
ddsd.dwHeight = 128;
hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface4, NULL);
ok(hr==DD_OK,"CreateSurface returned: %x\n",hr);
-
+if (FAILED(hr)) {
+ skip("failed to create surface4\n");
+ return;
+}
hr = IDirectDrawSurface7_AddAttachedSurface(surface1, surface2);
ok(hr == DDERR_CANNOTATTACHSURFACE, "Attaching an offscreen plain surface
to a front buffer returned %08x\n", hr);
hr = IDirectDrawSurface7_AddAttachedSurface(surface2, surface1);
@@ -1362,7 +1368,10 @@ static void AttachmentTest(void)
ddsd.dwHeight = GetSystemMetrics(SM_CYSCREEN);
hr = IDirectDraw_CreateSurface(lpDD, &ddsd, &surface3, NULL);
ok(hr==DD_OK,"CreateSurface returned: %x\n",hr);
-
+if (FAILED(hr)) {
+ skip("failed to create surface3\n");
+ return;
+ }
/* This one has a different size */
memset(&ddsd, 0, sizeof(ddsd));
ddsd.dwSize = sizeof(ddsd);
@@ -1372,7 +1381,10 @@ static void AttachmentTest(void)
ddsd.dwHeight = 128;
hr = IDirectDraw_CreateSurface(lpDD, &ddsd, &surface4, NULL);
ok(hr==DD_OK,"CreateSurface returned: %x\n",hr);
-
+if (FAILED(hr)) {
+ skip("failed to create surface4\n");
+ return;
+}
hr = IDirectDrawSurface_AddAttachedSurface(surface1, surface2);
ok(hr == DD_OK, "Attaching an offscreen plain surface to a front buffer
returned %08x\n", hr);
/* Try the reverse without detaching first */
@@ -2208,6 +2220,12 @@ static void SizeTest(void)
desc.dwWidth = 128; /* Keep them set to check what happens */
ret = IDirectDraw_CreateSurface(lpDD, &desc, &dsurface, NULL);
ok(ret == DD_OK, "Creating a primary surface without width and height info
returned %08x\n", ret);
+/* This should be handled but CreateSurface is failing */
+if (FAILED(ret))
+{
+skip("Can't create cubemap surface\n");
+return;
+}
if(dsurface)
{
ret = IDirectDrawSurface_GetSurfaceDesc(dsurface, &desc);
@@ -2492,7 +2510,7 @@ static void PaletteTest(void)
ok(hr==DD_OK, "CreateSurface returned: %x\n",hr);
if (FAILED(hr)) {
skip("failed to create surface\n");
- goto err;
+ return;
}
hr = IDirectDrawSurface_SetPalette(lpSurf, palette);
--
1.5.5.1
Re: Fix to exceptions in ddtest
Marcus Meissner wrote:
> On Sun, Oct 12, 2008 at 09:52:06PM -0400, Chris Ahrendt wrote:
>> Ok I have threaded through ddraw_test adding as I had them fail a check
>> and a fix in dsurface.c test. The test now fails when the CreateSurface
>> fails. Before this there were several point in the test where the return
>> status was not checked. As I encountered them and they failed with an
>> exception I added the failure I found at other parts which did the create
>> surface. For some reason a 3rd and 4th surface fails on ATI.
>>
>> Addached you will find the proposed fix.
>> I also found a point where the code did not skip but did a goto to the
>> error point with the variables unitialised.
>>
>>
>> Chris
>
>> >From 52071bddae683a1964d64be0acbfec8d7b2c2c5e Mon Sep 17 00:00:00 2001
>> From: Chris Ahrendt <[EMAIL PROTECTED]>
>> Date: Sun, 12 Oct 2008 21:44:21 -0400
>> Subject: [PATCH] Fix to ddtest to fail test if IDirectDraw_CreateSurface
>> failed.
>> Create Surface was failing and setting the handle to the surface to null.
>> So when the free / release was called it threw an exception instead of
>> failing the test.
>>
>> ---
>> ok(rc==DDERR_INVALIDPARAMS,"CreateSurface returned: %x\n",rc);
>> -
>> +if (FAILED(rc)) {
>> + skip("failed to create surface\n");
>> + return;
>> + }
>
> here it is _expected_ that the surface creation fails. So this code is not
> useful. ALso in other places.
>
> ciao, Marcus
Ok that I can fix easy enough...
chris
Fix to exceptions in ddtest
Ok I have threaded through ddraw_test adding as I had them fail a check
and a fix in dsurface.c test. The test now fails when the CreateSurface
fails. Before this there were several point in the test where the return
status was not checked. As I encountered them and they failed with an
exception I added the failure I found at other parts which did the
create surface. For some reason a 3rd and 4th surface fails on ATI.
Addached you will find the proposed fix.
I also found a point where the code did not skip but did a goto to the
error point with the variables unitialised.
Chris
>From 52071bddae683a1964d64be0acbfec8d7b2c2c5e Mon Sep 17 00:00:00 2001
From: Chris Ahrendt <[EMAIL PROTECTED]>
Date: Sun, 12 Oct 2008 21:44:21 -0400
Subject: [PATCH] Fix to ddtest to fail test if IDirectDraw_CreateSurface failed.
Create Surface was failing and setting the handle to the surface to null.
So when the free / release was called it threw an exception instead of failing
the test.
---
dlls/ddraw/tests/dsurface.c | 92 ++-
1 files changed, 73 insertions(+), 19 deletions(-)
diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c
index fc7bb88..4f545d9 100644
--- a/dlls/ddraw/tests/dsurface.c
+++ b/dlls/ddraw/tests/dsurface.c
@@ -198,7 +198,10 @@ static void MipMapCreationTest(void)
ddsd.dwHeight = 32;
rc = IDirectDraw_CreateSurface(lpDD, &ddsd, &lpDDSMipMapTest, NULL);
ok(rc==DDERR_INVALIDPARAMS,"CreateSurface returned: %x\n",rc);
-
+if (FAILED(rc)) {
+ skip("failed to create surface\n");
+ return;
+ }
/* Destroy the surface. */
if( rc == DD_OK )
IDirectDrawSurface_Release(lpDDSMipMapTest);
@@ -1004,7 +1007,10 @@ static void EnumTest(void)
ddsd.dwHeight = 32;
rc = IDirectDraw_CreateSurface(lpDD, &ddsd, &surface, NULL);
ok(rc==DD_OK,"CreateSurface returned: %x\n",rc);
-
+if (FAILED(rc)) {
+ skip("failed to create surface\n");
+ return;
+ }
memset(&ctx, 0, sizeof(ctx));
ctx.expected[0] = surface;
rc = IDirectDrawSurface_GetAttachedSurface(ctx.expected[0], &ddsd.ddsCaps,
&ctx.expected[1]);
@@ -1055,7 +1061,10 @@ static void AttachmentTest7(void)
ddsd.dwHeight = 128;
hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface1, NULL);
ok(hr==DD_OK,"CreateSurface returned: %x\n",hr);
-
+if (FAILED(hr)) {
+ skip("failed to create surface\n");
+ return;
+ }
/* ROOT */
num = 0;
IDirectDrawSurface7_EnumAttachedSurfaces(surface1, &num, SurfaceCounter);
@@ -1092,7 +1101,10 @@ static void AttachmentTest7(void)
ddsd.dwHeight = 16;
hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface2, NULL);
ok(hr==DD_OK,"CreateSurface returned: %x\n",hr);
-
+if (FAILED(hr)) {
+ skip("failed to create surface2\n");
+ return;
+ }
hr = IDirectDrawSurface7_AddAttachedSurface(surface1, surface2);
ok(hr == DDERR_CANNOTATTACHSURFACE, "Attaching a 16x16 surface to a
128x128 texture root returned %08x\n", hr);
hr = IDirectDrawSurface7_AddAttachedSurface(surface2, surface1);
@@ -1112,7 +1124,10 @@ static void AttachmentTest7(void)
ddsd.dwHeight = 16;
hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface2, NULL);
ok(hr==DD_OK,"CreateSurface returned: %x\n",hr);
-
+if (FAILED(hr)) {
+ skip("failed to create surface\n");
+ return;
+ }
hr = IDirectDrawSurface7_AddAttachedSurface(surface1, surface2);
ok(hr == DDERR_CANNOTATTACHSURFACE, "Attaching a 16x16 offscreen plain
surface to a 128x128 texture root returned %08x\n", hr);
hr = IDirectDrawSurface7_AddAttachedSurface(surface2, surface1);
@@ -1136,7 +1151,10 @@ static void AttachmentTest7(void)
ddsd.dwBackBufferCount = 2;
hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface1, NULL);
ok(hr==DD_OK,"CreateSurface returned: %x\n",hr);
-
+if (FAILED(hr)) {
+ skip("failed to create surface\n");
+ return;
+ }
num = 0;
IDirectDrawSurface7_EnumAttachedSurfaces(surface1, &num, SurfaceCounter);
ok(num == 1, "Primary surface has %d surfaces attached, expected 1\n",
num);
@@ -1149,13 +1167,20 @@ static void AttachmentTest7(void)
ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE | DDSCAPS_FRONTBUFFER;
hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface1, NULL);
ok(hr==DDERR_INVALIDCAPS,"CreateSurface returned: %x\n",hr);
+if (FAILED(hr)) {
+ skip("failed to create surface1\n");
+ return;
+ }
memset(&ddsd, 0, sizeof(ddsd));
ddsd.dwSize = sizeof(ddsd);
ddsd.dwFlags = DDSD_CAPS;
ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE | DDSCAPS_BACKBUFFER;
Re: Latest Windows Conformance Tests
Vitaliy Margolen wrote: > Chris Ahrendt wrote: >> Causes windows XP SP3 to reboot during d3d test.. > > Would you please stop hijacking threads! Do NOT reply when starting a new > topic!!! This is highly annoying and it's deemed a really bad habit. > > Vitaliy. I did not hijack a thread I opened a brand new note thank you... and I was talking about the windows conformance tests which I am running on my home machine... So before you jump on someone by assuming like you prefer to do Vitaliy why dont you ask if this is one or not Again havent hijacked a thread.. this is a new thread with a problem I just got by running on a WINDOWS machine the WINE CONFORMANCE TEST from http://www.winehq.org/site/docs/winedev-guide/testing-windows using the precompiled binaries link from that page... So if you dont mind I would like an appology for you butting in and claiming that I am doing something I most certainly am not doing. Chris
Re: Latest Windows Conformance Tests
James Hawkins wrote: > On Sun, Oct 12, 2008 at 2:02 PM, Chris Ahrendt <[EMAIL PROTECTED]> wrote: >> Causes windows XP SP3 to reboot during d3d test.. >> >> What and where do I need to send in the information >> on the issue. >> > > You're going to have to set up a cross-build environment to compile > the d3d tests and figure out which test exactly is causing your > machine to reboot. > so standard VC++ etc? Chris
Latest Windows Conformance Tests
Causes windows XP SP3 to reboot during d3d test.. What and where do I need to send in the information on the issue. Microsoft Windows XP Home Edition Version 2002 Sp 3 Pent 4 3.2ghz 2 gig ram Chris
