Re: [1/2] gdi32: Added PolyDraw tests to tests/path.c [try2]
On Fri, 2007-06-29 at 14:49 -0700, Evan Stade wrote: > Thanks a lot for your help. No prob. > > Your shorter diff may make the tests conform, but it incorrectly > assigns lastmove.x = dc->CursPosX. This only makes it conform to the > tests because the tests happen to have a MoveToEx as the last path > point before the PolyDraw is called. You should include this in your tests, e.g., by calling LineTo after the MoveToEx and before the first PolyDraw. This immediately makes it clear why you need to have separate path and non-path cases. (I personally think about conformance tests like this - you worked hard to figure out how the function works on native and implemented your own version, but someone might commit a patch sometime in the future to fix something else that screws up all your hard work; that's why you need to put this knowledge into conformance tests, so once that feature is implemented in wine it will never break again). > Also, your diff doesn't > correctly check the point types. The test if( lpbTypes[i] == > PT_MOVETO) (which was there before your changes) is wrong because it > returns false for PT_MOVETO | PT_LINETO, when it should return true > (according to my testing which was not a part of the test I > submitted). Also, your diff does not MoveToEx to orig_pos at the > second "return FALSE". This is incorrect but again does not show up > in the tests. Again, these are things that should ideally be a part of your conformance test. That would make the rationale for your extensive changes in your second patch clearer and would improve the likelihood of the patches going in. > > So while a small and simple diff can make these specific tests > conform, it is not correct. However I still don't understand how this > influences whether the test patch got accepted. Your explanation of > why the fix patch didn't get accepted on the other hand does make > sense. > I am not sure why the test patch was not accepted (unless maybe Alexandre wants both patches ready to go before committing either, as if you make any changes to the second one you might find you need to add something to the tests... don't know), but having the whole patchset complete and good to go certainly wouldn't hurt either patch. Misha
Re: request to change appdb message
On 6/29/07, Ben Hodgetts <[EMAIL PROTECTED]> wrote:
Chris Morgan wrote:
> On 6/29/07, Chris Morgan <[EMAIL PROTECTED]> wrote:
>> On 6/29/07, Jesse Allen <[EMAIL PROTECTED]> wrote:
>> > On 6/29/07, Louis Lenders <[EMAIL PROTECTED]> wrote:
>> > >
>> > > Yeah, so maybe we could add a list of "Common failures" to the
>> documention,
>> > > with the solution. I can live with that. Then we could point
>> garbage test
>> > > submitters to that page. That would be a nice work around. I'll
>> have to
>> > > figure out how wiki works, and then i could give it a shot
>> lateron i guess.
>> > >
>> > > Something like:
>> > >
>> > > Problem:
>> > > err:module:import_dll Library MSVBVM60.DLL (needed by
>> L"C:\\app.exe")
>> > > not found
>> > > err:module:LdrInitializeThunk Main exe initialization for
>> L"C:\\app.exe"
>> > > failed,status c135
>> > >
>> > > Solution:
>> > > winetricks vcrun60
>> > >
>> > > or
>> > >
>> > > Problem:
>> > > wine app.exe
>> > > err:ole:CoGetClassObject class
>> {0514--0010-8000-00aa006d2ea4}
>> > > not registered
>> > > err:ole:create_server class {0514--0010-8000-00aa006d2ea4}
>> > > not registered
>> > > err:ole:CoGetClassObject no class object
>> > > {0514--0010-8000-00aa006d2ea4}could be created for
>> > > context 0x5
>> > > Unhandled page fault etc.
>> > >
>> > > Solution:
>> > > winetricks mdac27
>> > >
>> > > Would that be something useful?
>> > >
>> > > Cheers, Louis
>> > >
>> > >
>> > >
>> >
>> > Well, yeah. But the maintainer should be doing that already using
>> > appdb notes based on his own knowledge or reading test reports. The
>> > maintainer already screens the reports. So I can't see why we need to
>> > be more automatic.
>> >
>> > However we should set up a wiki for common problems or procedures so
>> > the maintainer can link to them from the notes.
>> >
>>
>> Checking it automatically lets us skip the round trip of submission,
>> review, rejection and resubmission. We can check the submission and
>> report suggestions before the user even submits the test results, thus
>> avoiding the problem where each of our 800+ maintainers knows about
>> those problems.
>
> That last sentence should have been "where each of our 800+ maintainer
> has to know about those problems and common solutions".
>
> Chris
>
>
I think the main problem is that there is a lack of maintainers and the
ones that exist seem to be mainly inactive. If they were active then
there would already be notes pointing to easy fixes for the apps like
NoCD patches, d3dx9xx.dll files, etc. I agree a pre-parser for common
issues would be nice, but probably quite a bit of coding work and likely
to get many wrong hits. It's a messy situation really.
It isn't all that complex. It would require someone to start to
collect common debug output from users and then look at how we might
look for particular dlls or errors to identify the particular issue.
For someone with lots of experience it wouldn't seem to be all that
difficult but it really depends on how generic some errors are.
Chris
Re: request to change appdb message
Chris Morgan wrote:
On 6/29/07, Chris Morgan <[EMAIL PROTECTED]> wrote:
On 6/29/07, Jesse Allen <[EMAIL PROTECTED]> wrote:
> On 6/29/07, Louis Lenders <[EMAIL PROTECTED]> wrote:
> >
> > Yeah, so maybe we could add a list of "Common failures" to the
documention,
> > with the solution. I can live with that. Then we could point
garbage test
> > submitters to that page. That would be a nice work around. I'll
have to
> > figure out how wiki works, and then i could give it a shot
lateron i guess.
> >
> > Something like:
> >
> > Problem:
> > err:module:import_dll Library MSVBVM60.DLL (needed by
L"C:\\app.exe")
> > not found
> > err:module:LdrInitializeThunk Main exe initialization for
L"C:\\app.exe"
> > failed,status c135
> >
> > Solution:
> > winetricks vcrun60
> >
> > or
> >
> > Problem:
> > wine app.exe
> > err:ole:CoGetClassObject class
{0514--0010-8000-00aa006d2ea4}
> > not registered
> > err:ole:create_server class {0514--0010-8000-00aa006d2ea4}
> > not registered
> > err:ole:CoGetClassObject no class object
> > {0514--0010-8000-00aa006d2ea4}could be created for
> > context 0x5
> > Unhandled page fault etc.
> >
> > Solution:
> > winetricks mdac27
> >
> > Would that be something useful?
> >
> > Cheers, Louis
> >
> >
> >
>
> Well, yeah. But the maintainer should be doing that already using
> appdb notes based on his own knowledge or reading test reports. The
> maintainer already screens the reports. So I can't see why we need to
> be more automatic.
>
> However we should set up a wiki for common problems or procedures so
> the maintainer can link to them from the notes.
>
Checking it automatically lets us skip the round trip of submission,
review, rejection and resubmission. We can check the submission and
report suggestions before the user even submits the test results, thus
avoiding the problem where each of our 800+ maintainers knows about
those problems.
That last sentence should have been "where each of our 800+ maintainer
has to know about those problems and common solutions".
Chris
I think the main problem is that there is a lack of maintainers and the
ones that exist seem to be mainly inactive. If they were active then
there would already be notes pointing to easy fixes for the apps like
NoCD patches, d3dx9xx.dll files, etc. I agree a pre-parser for common
issues would be nice, but probably quite a bit of coding work and likely
to get many wrong hits. It's a messy situation really.
Ben H.
Re: [1/2] gdi32: Added PolyDraw tests to tests/path.c [try2]
On 6/29/07, Koshelev, Misha Vladislavo <[EMAIL PROTECTED]> wrote: On 6/27/07, Evan Stade wrote: > Hi, > > [try2] The patch I sent yesterday was not properly todo_wined. Also, > this test is a bit more extensive (about twice as many points drawn). > It uses various point-type combination (even non-sensical ones such as > PT_LINETO | PT_MOVETO) to test the exact logic of PolyDraw with an > open path. > > changelog: > * added polydraw test to path testing (5 more todo_wines) > > dlls/gdi32/tests/path.c | 70 +++ > 1 files changed, 70 insertions(+), 0 deletions(-) > > -- > Evan Stade > > Also, I'd add a PT_MOVETO into your first PolyDraw call so you can tell whether PT_CLOSEFIGURE adds a PT_MOVETO to orig_pos or lastmove, as the current version does not differentiate this. Misha Thanks a lot for your help. Your shorter diff may make the tests conform, but it incorrectly assigns lastmove.x = dc->CursPosX. This only makes it conform to the tests because the tests happen to have a MoveToEx as the last path point before the PolyDraw is called. Also, your diff doesn't correctly check the point types. The test if( lpbTypes[i] == PT_MOVETO) (which was there before your changes) is wrong because it returns false for PT_MOVETO | PT_LINETO, when it should return true (according to my testing which was not a part of the test I submitted). Also, your diff does not MoveToEx to orig_pos at the second "return FALSE". This is incorrect but again does not show up in the tests. So while a small and simple diff can make these specific tests conform, it is not correct. However I still don't understand how this influences whether the test patch got accepted. Your explanation of why the fix patch didn't get accepted on the other hand does make sense. -- Evan Stade
Re: request to change appdb message
On 6/29/07, Chris Morgan <[EMAIL PROTECTED]> wrote:
On 6/29/07, Jesse Allen <[EMAIL PROTECTED]> wrote:
> On 6/29/07, Louis Lenders <[EMAIL PROTECTED]> wrote:
> >
> > Yeah, so maybe we could add a list of "Common failures" to the documention,
> > with the solution. I can live with that. Then we could point garbage test
> > submitters to that page. That would be a nice work around. I'll have to
> > figure out how wiki works, and then i could give it a shot lateron i guess.
> >
> > Something like:
> >
> > Problem:
> > err:module:import_dll Library MSVBVM60.DLL (needed by L"C:\\app.exe")
> > not found
> > err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe"
> > failed,status c135
> >
> > Solution:
> > winetricks vcrun60
> >
> > or
> >
> > Problem:
> > wine app.exe
> > err:ole:CoGetClassObject class {0514--0010-8000-00aa006d2ea4}
> > not registered
> > err:ole:create_server class {0514--0010-8000-00aa006d2ea4}
> > not registered
> > err:ole:CoGetClassObject no class object
> > {0514--0010-8000-00aa006d2ea4}could be created for
> > context 0x5
> > Unhandled page fault etc.
> >
> > Solution:
> > winetricks mdac27
> >
> > Would that be something useful?
> >
> > Cheers, Louis
> >
> >
> >
>
> Well, yeah. But the maintainer should be doing that already using
> appdb notes based on his own knowledge or reading test reports. The
> maintainer already screens the reports. So I can't see why we need to
> be more automatic.
>
> However we should set up a wiki for common problems or procedures so
> the maintainer can link to them from the notes.
>
Checking it automatically lets us skip the round trip of submission,
review, rejection and resubmission. We can check the submission and
report suggestions before the user even submits the test results, thus
avoiding the problem where each of our 800+ maintainers knows about
those problems.
That last sentence should have been "where each of our 800+ maintainer
has to know about those problems and common solutions".
Chris
Re: Announcing WineConf 2007
On 6/29/07, Mike Hearn <[EMAIL PROTECTED]> wrote: 6th/7th October. Be there or be square. If anyone from the US is planing on attending and does not currently have your passport, you need to apply for it NOW. Due to insane US policy there is about a 3 month backlog on passport application processing. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: request to change appdb message
On 6/29/07, Jesse Allen <[EMAIL PROTECTED]> wrote:
On 6/29/07, Louis Lenders <[EMAIL PROTECTED]> wrote:
>
> Yeah, so maybe we could add a list of "Common failures" to the documention,
> with the solution. I can live with that. Then we could point garbage test
> submitters to that page. That would be a nice work around. I'll have to
> figure out how wiki works, and then i could give it a shot lateron i guess.
>
> Something like:
>
> Problem:
> err:module:import_dll Library MSVBVM60.DLL (needed by L"C:\\app.exe")
> not found
> err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe"
> failed,status c135
>
> Solution:
> winetricks vcrun60
>
> or
>
> Problem:
> wine app.exe
> err:ole:CoGetClassObject class {0514--0010-8000-00aa006d2ea4}
> not registered
> err:ole:create_server class {0514--0010-8000-00aa006d2ea4}
> not registered
> err:ole:CoGetClassObject no class object
> {0514--0010-8000-00aa006d2ea4}could be created for
> context 0x5
> Unhandled page fault etc.
>
> Solution:
> winetricks mdac27
>
> Would that be something useful?
>
> Cheers, Louis
>
>
>
Well, yeah. But the maintainer should be doing that already using
appdb notes based on his own knowledge or reading test reports. The
maintainer already screens the reports. So I can't see why we need to
be more automatic.
However we should set up a wiki for common problems or procedures so
the maintainer can link to them from the notes.
Checking it automatically lets us skip the round trip of submission,
review, rejection and resubmission. We can check the submission and
report suggestions before the user even submits the test results, thus
avoiding the problem where each of our 800+ maintainers knows about
those problems.
Chris
Announcing WineConf 2007
Yes, it's true! The moment you've all been waiting for! On 6th/7th October, once more Wine hackers from around the world will meet to eat, drink, make merry, and discuss the finer details of reimplementing the Windows API. This year it's Googles turn to host it, and it'll be at the engineering office in Zurich. You too can chill out with these awesome froods by signing up for the wineconf mailing list, and surfing over to: http://wiki.winehq.org/WineConf2007 ... which is currently a bit sparse but will populate nearer the time. Fascinating talks! Interesting people! Hackfests galore ... and maybe even fondue! 6th/7th October. Be there or be square.
Re: request to change appdb message
On 6/29/07, Louis Lenders <[EMAIL PROTECTED]> wrote:
Yeah, so maybe we could add a list of "Common failures" to the documention,
with the solution. I can live with that. Then we could point garbage test
submitters to that page. That would be a nice work around. I'll have to
figure out how wiki works, and then i could give it a shot lateron i guess.
Something like:
Problem:
err:module:import_dll Library MSVBVM60.DLL (needed by L"C:\\app.exe")
not found
err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe"
failed,status c135
Solution:
winetricks vcrun60
or
Problem:
wine app.exe
err:ole:CoGetClassObject class {0514--0010-8000-00aa006d2ea4}
not registered
err:ole:create_server class {0514--0010-8000-00aa006d2ea4}
not registered
err:ole:CoGetClassObject no class object
{0514--0010-8000-00aa006d2ea4}could be created for
context 0x5
Unhandled page fault etc.
Solution:
winetricks mdac27
Would that be something useful?
Cheers, Louis
Well, yeah. But the maintainer should be doing that already using
appdb notes based on his own knowledge or reading test reports. The
maintainer already screens the reports. So I can't see why we need to
be more automatic.
However we should set up a wiki for common problems or procedures so
the maintainer can link to them from the notes.
Re: Add combobox in winecfg:theme.c
В сообщении от 16 июня 2007 Yaroslav Skorokhodov написал(a): > Changelog > Add combobox for select base font size There was improvement allows select size of the base font (dpi actually) in LogPixel registry entry. It is useful thing (default font size is too small on 17" monitors). What's wrong with the patch? http://www.winehq.org/pipermail/wine-patches/2007-June/040496.html -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru
Re: [1/2] gdi32: Added PolyDraw tests to tests/path.c [try2]
On 6/27/07, Evan Stade wrote: > Hi, > > [try2] The patch I sent yesterday was not properly todo_wined. Also, > this test is a bit more extensive (about twice as many points drawn). > It uses various point-type combination (even non-sensical ones such as > PT_LINETO | PT_MOVETO) to test the exact logic of PolyDraw with an > open path. > > changelog: > * added polydraw test to path testing (5 more todo_wines) > > dlls/gdi32/tests/path.c | 70 > +++ > 1 files changed, 70 insertions(+), 0 deletions(-) > > -- > Evan Stade > > Also, I'd add a PT_MOVETO into your first PolyDraw call so you can tell whether PT_CLOSEFIGURE adds a PT_MOVETO to orig_pos or lastmove, as the current version does not differentiate this. Misha
Re: request to change appdb message
On 6/29/07, Louis Lenders <[EMAIL PROTECTED]> wrote:
Chris Morgan gmail.com> writes:
>
> How do you normally judge if the result is valid or not? What if the
> result says that everything works?
Basically i'm only talking about garbage test results. If the app is
gold/platinum there's of course no need to paste debug output
>It seems like any result could be faked, and we can't reject a test result
>from
>a user that had problem just because a handful of other users didn't.
>
Yeah, i agree, there's no way to solve that.
> What else can we do with the issue you raised in #1? If users report
> their app doesn't work but don't report the crash data then at least
> we know the app doesn't work and thats valuable data. If it is too
> difficult to report bugs in bugzilla we should see if there are ways
> to assist with this.
I don't think it's too difficult, most users just don't bother to do this.
>
> I'm not entirely sure what your point #2 is. You are arguing that we
> want to see crash results in test submissions because then we can
> reply with a suggestion about how to fix the issue? It seems like this
> is exactly the kind of thing we want in bugzilla since it reflects
> issues users have with Wine.
Unfortunately , if anyone would open a bug with the example
>i gave in issue #2,it would be closed immediately with a comment
"Invalid" -> "Closing".
>
> I guess my point about #2 is that assuming the user didn't do
> something really crazy, the issues the user has tend to be
> deficiencies in wine or its documentation and these really are
> legitimate issues that should be addressed.
Yeah, so maybe we could add a list of "Common failures" to the documention,
with the solution. I can live with that. Then we could point garbage test
submitters to that page. That would be a nice work around. I'll have to
figure out how wiki works, and then i could give it a shot lateron i guess.
Something like:
Problem:
err:module:import_dll Library MSVBVM60.DLL (needed by L"C:\\app.exe")
not found
err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe"
failed,status c135
Solution:
winetricks vcrun60
or
Problem:
wine app.exe
err:ole:CoGetClassObject class {0514--0010-8000-00aa006d2ea4}
not registered
err:ole:create_server class {0514--0010-8000-00aa006d2ea4}
not registered
err:ole:CoGetClassObject no class object
{0514--0010-8000-00aa006d2ea4}could be created for
context 0x5
Unhandled page fault etc.
Solution:
winetricks mdac27
Would that be something useful?
This sounds like a good idea. What about this nutty implementation.
Why not come up with some logic to scan the contents of test results
that a user is attempting to submit to the appdb? We could pass them
through the scanner and repost the test result with additional
comments that would try to address the users issues or at least point
them at the faq.
This would require a minor amount of php hacking but if you wanted to
help out on the php code for the logic and suggestions I could get the
architecture in place. The logic portion should be pretty simple,
compared to knowing where to integrate things.
Also note that we use a test suite with the appdb that can be run from
the command line. This would let us save several example pieces of
text to test that we respond reasonably to different issues.
What do you think?
Chris
Re: The: "Wine Status - ChangeLog"
[EMAIL PROTECTED] schreef: > This page has been dead since October 1. > > Since I'm not producing code for the Wine project, this is an area I'd like to > contribute to. (I'm already taking screenshots of the API status page to see > what happens from release to release :)) > > Is there some WineHQ folks here that would be willing to give me accsess? > You can check out the source of the website. Then you just make your changes and submit them to [EMAIL PROTECTED] with [Lostwages] in title. If I'm wrong someone correct me, Maarten
The: "Wine Status - ChangeLog"
This page has been dead since October 1. Since I'm not producing code for the Wine project, this is an area I'd like to contribute to. (I'm already taking screenshots of the API status page to see what happens from release to release :)) Is there some WineHQ folks here that would be willing to give me accsess? Regards.
Re: Something wrong with my two patches?
Markus Gömmel <[EMAIL PROTECTED]> writes: > On 21 and 22 June I submitted two small patches (for > comctl32/datetime.c and user32/msgbox.c). Both should be ok, but > definitly the first one (datetime.c)... > > Something wrong with them or only some normal delay in putting them > into git? My last small patch went into git within 2 days... Your mails contain two copies of the patch, one of which is mangled, that's a real pain to deal with. Please fix your mail setup and send a single correct version of each patch. -- Alexandre Julliard [EMAIL PROTECTED]
Re: illegal characters in file names
On Friday 29 June 2007, Alexandre Julliard wrote: > > On Wine the list of characters is: > > > > /:<>| > > Where did you find that list? The "official" list is INVALID_NT_CHARS > in ntdll/directory.c and it should match the NT one. Looks like the list of (printable) characters that shlwapi.PathIsValidChar rejects. -Hans
Re: illegal characters in file names
"Lei Zhang" <[EMAIL PROTECTED]> writes: > On Wine the list of characters is: > > /:<>| Where did you find that list? The "official" list is INVALID_NT_CHARS in ntdll/directory.c and it should match the NT one. -- Alexandre Julliard [EMAIL PROTECTED]
Re: illegal characters in file names
On Thursday 28 June 2007, Lei Zhang wrote: > On Wine the list of characters is: > > /:<>| > > and on Windows, it is: > > \/:*?"<>| > > Is this intentional or something we should fix? I suspect that the list of invalid characters is filesystem dependent on Windows (e.g. ntfs vs fat32), which may explain why we can allow more characters. Do you have an app that breaks because of this? -Hans
Re: make test in winsock segfaulting after patch 4c5b55a0f8...
On Friday 29 June 2007 09:21:03 Kai Blin wrote: > commit 4c5b55a0f82e83793814a21eadec8b50d48751f3 > Author: Alexandre Julliard <[EMAIL PROTECTED]> > Date: Mon Jun 4 18:16:48 2007 +0200 > > server: Run async I/O APCs from the SIGUSR1 handler. > > I have attached the backtrace. Looking at bug 8791, I can confirm this only happens with WINEDEBUG=+winsock. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. pgpRAvRrDC7kH.pgp Description: PGP signature
Re: request to change appdb message
Chris Morgan gmail.com> writes:
>
> How do you normally judge if the result is valid or not? What if the
> result says that everything works?
Basically i'm only talking about garbage test results. If the app is
gold/platinum there's of course no need to paste debug output
>It seems like any result could be faked, and we can't reject a test result
>from
>a user that had problem just because a handful of other users didn't.
>
Yeah, i agree, there's no way to solve that.
> What else can we do with the issue you raised in #1? If users report
> their app doesn't work but don't report the crash data then at least
> we know the app doesn't work and thats valuable data. If it is too
> difficult to report bugs in bugzilla we should see if there are ways
> to assist with this.
I don't think it's too difficult, most users just don't bother to do this.
>
> I'm not entirely sure what your point #2 is. You are arguing that we
> want to see crash results in test submissions because then we can
> reply with a suggestion about how to fix the issue? It seems like this
> is exactly the kind of thing we want in bugzilla since it reflects
> issues users have with Wine.
Unfortunately , if anyone would open a bug with the example
>i gave in issue #2,it would be closed immediately with a comment
"Invalid" -> "Closing".
>
> I guess my point about #2 is that assuming the user didn't do
> something really crazy, the issues the user has tend to be
> deficiencies in wine or its documentation and these really are
> legitimate issues that should be addressed.
Yeah, so maybe we could add a list of "Common failures" to the documention,
with the solution. I can live with that. Then we could point garbage test
submitters to that page. That would be a nice work around. I'll have to
figure out how wiki works, and then i could give it a shot lateron i guess.
Something like:
Problem:
err:module:import_dll Library MSVBVM60.DLL (needed by L"C:\\app.exe")
not found
err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe"
failed,status c135
Solution:
winetricks vcrun60
or
Problem:
wine app.exe
err:ole:CoGetClassObject class {0514--0010-8000-00aa006d2ea4}
not registered
err:ole:create_server class {0514--0010-8000-00aa006d2ea4}
not registered
err:ole:CoGetClassObject no class object
{0514--0010-8000-00aa006d2ea4}could be created for
context 0x5
Unhandled page fault etc.
Solution:
winetricks mdac27
Would that be something useful?
Cheers, Louis
Re: WinXP winsock test broken by commit e39dca6af6c87a30ab1d907c0468de2602a6e442
Damjan Jovanovic wrote: On 6/28/07, Kai Blin <[EMAIL PROTECTED]> wrote: The tests added in patch commit e39dca6af6c87a30ab1d907c0468de2602a6e442 Author: Damjan Jovanovic <[EMAIL PROTECTED]> Date: Thu Mar 22 08:03:28 2007 +0200 ws2_32: WSASendTo should always re-enable the FD_WRITE event. break the ws2_32 sock.c tests on WinXP SP2. sock.c:1832: Test failed: WaitForSingleObject failed, error 258 Really strange, I remember that test passing when I wrote it. I'm afraid I don't really know what's going wrong there. I'll run the tests myself this weekend. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. Damjan Briefly looking at http://test.winehq.org/data agrees with Kai's findings. Ever since the March 23 version of winetest, this test is failing for all NT4+ systems. Cheers, PAul.
Re: WinXP winsock test broken by commit e39dca6af6c87a30ab1d907c0468de2602a6e442
On 6/28/07, Kai Blin <[EMAIL PROTECTED]> wrote: The tests added in patch commit e39dca6af6c87a30ab1d907c0468de2602a6e442 Author: Damjan Jovanovic <[EMAIL PROTECTED]> Date: Thu Mar 22 08:03:28 2007 +0200 ws2_32: WSASendTo should always re-enable the FD_WRITE event. break the ws2_32 sock.c tests on WinXP SP2. sock.c:1832: Test failed: WaitForSingleObject failed, error 258 Really strange, I remember that test passing when I wrote it. I'm afraid I don't really know what's going wrong there. I'll run the tests myself this weekend. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. Damjan
make test in winsock segfaulting after patch 4c5b55a0f8...
The following commit breaks the winsock test for me. commit 4c5b55a0f82e83793814a21eadec8b50d48751f3 Author: Alexandre Julliard <[EMAIL PROTECTED]> Date: Mon Jun 4 18:16:48 2007 +0200 server: Run async I/O APCs from the SIGUSR1 handler. I have attached the backtrace. This is currently stopping me from confirming if my WSAStringToAddress patch is correct. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. trace:winsock:DllMain 0x6040 0x3 (nil) wine: Unhandled page fault on read access to 0x at address 0x7618d8df (thread 000f), starting debugger... Unhandled exception: page fault on read access to 0x in 32-bit code (0x7618d8df). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7618d8df ESP:7ece6840 EBP:7ece68a8 EFLAGS:00010206( - 00 - RIP1) EAX: EBX:761b14f4 ECX:761b97a4 EDX:7ffd8f10 ESI:7ffd6000 EDI: Stack dump: 0x7ece6840: 761b14f4 761b14f4 7ece6858 7616c05b 0x7ece6850: 00110020 603839e4 7ece6938 7615ec11 0x7ece6860: 0011 00126140 761b14f4 0x7ece6870: 761cbb3c 761cbb3c 7ece68a8 761705b2 0x7ece6880: 0011 00126140 0x7ece6890: 7ece6938 7618d8bb 761b14f4 Backtrace: =>1 0x7618d8df server_exit_thread+0x2f(status=0x0) [/home/kai/wine/build/dlls/ntdll/../../../wine-git/dlls/ntdll/server.c:147] in ntdll (0x7ece68a8) 2 0x76193e32 in ntdll (+0x43e32) (0x7ece68b8) 3 0x60363cfb in kernel32 (+0x73cfb) (0x7ece6948) 4 0x64a86f0b client_stop+0xab() [/home/kai/wine/build/dlls/ws2_32/tests/../../../../wine-git/dlls/ws2_32/tests/sock.c:382] in ws2_32_test (0x7ece6978) 5 0x64a8833c event_client+0x21c(par=0x64a90ccc) [/home/kai/wine/build/dlls/ws2_32/tests/../../../../wine-git/dlls/ws2_32/tests/sock.c:755] in ws2_32_test (0x7ece6a18) 6 0x7619326e call_thread_entry_point+0xe() in ntdll (0x7ece6a28) 7 0x76193f42 call_thread_func+0x42(rtl_func=, arg=) [/home/kai/wine/build/dlls/ntdll/../../../wine-git/dlls/ntdll/thread.c:404] in ntdll (0x7ece6ac8) 8 0x761941df in ntdll (+0x441df) (0x7ece73c8) 9 0x601362fb (0x7ece74b8) 10 0x6021993e (0x) 0x7618d8df server_exit_thread+0x2f [/home/kai/wine/build/dlls/ntdll/../../../wine-git/dlls/ntdll/server.c:147] in ntdll: movl %edx,0x0(%eax) 147 RemoveEntryList( &NtCurrentTeb()->TlsLinks ); Modules: Module Address Debug info Name (22 modules) ELF 45135000-45149000 Deferredlibresolv.so.2 ELF 48599000-485b6000 Deferredld-linux.so.2 ELF 48f6a000-490be000 Deferredlibc.so.6 ELF 490c-490e9000 Deferredlibm.so.6 ELF 490eb000-490f Deferredlibdl.so.2 ELF 4910f000-49127000 Deferredlibpthread.so.0 ELF 4946e000-4947a000 Deferredlibgcc_s.so.1 ELF 6001d000-60131000 Deferredlibwine.so.1 ELF 602cb000-602d7000 Deferredlibnss_files.so.2 ELF 602d7000-603fc000 Dwarf kernel32 \-PE 602f-603fc000 \ kernel32 ELF 603fc000-60427000 Deferredws2_32 \-PE 6040-60427000 \ ws2_32 ELF 60427000-60445000 Deferrediphlpapi \-PE 6043-60445000 \ iphlpapi ELF 60459000-6049f000 Deferredadvapi32 \-PE 6046-6049f000 \ advapi32 ELF 64a74000-64a91000 Dwarf ws2_32_test \-PE 64a8-64a91000 \ ws2_32_test ELF 76136000-761cd000 Dwarf ntdll \-PE 7615-761cd000 \ ntdll ELF 7bf0-7bf03000 Deferred Threads: process tid prio (all id:s are in hex) 0008 (D) H:\wine\build\dlls\ws2_32\tests\ws2_32_test.exe 000f0 <== 000e0 00090 pgpB5KZr3021K.pgp Description: PGP signature
