2008/10/8 Chris Ahrendt celticht32@aol.com:
per dan resending
chris
From e8ec03471e1206ea93fa6224d7c6b8b61422d80e Mon Sep 17 00:00:00 2001 From: Chris Ahrendt celticht32@aol.com Date: Tue, 7 Oct 2008 21:02:36 -0400 Subject: [PATCH] Checked all the states of variables in test to ensure that they are not NULL
This broad-sweep approach is not correct. If there is a machine that is crashing on a NULL interface, then a check needs to be added where that machine returns a NULL interface and we should then skip those particular tests. There are plenty of examples of this you can look for.
James Hawkins wrote:
2008/10/8 Chris Ahrendt celticht32@aol.com:
per dan resending
chris
From e8ec03471e1206ea93fa6224d7c6b8b61422d80e Mon Sep 17 00:00:00 2001 From: Chris Ahrendt celticht32@aol.com Date: Tue, 7 Oct 2008 21:02:36 -0400 Subject: [PATCH] Checked all the states of variables in test to ensure that they are not NULL
This broad-sweep approach is not correct. If there is a machine that is crashing on a NULL interface, then a check needs to be added where that machine returns a NULL interface and we should then skip those particular tests. There are plenty of examples of this you can look for.
It was not a broad sweep... I know where it crashed and am checking there. However, I noticed there were several other places were at sometimes it checked for null and other places it did not.. so I went through and made sure all of the ones without the check now have the check.
Chris
On Wed, Oct 8, 2008 at 10:05 PM, Chris Ahrendt celticht32@aol.com wrote:
It was not a broad sweep... I know where it crashed and am checking there. However, I noticed there were several other places were at sometimes it checked for null and other places it did not.. so I went through and made sure all of the ones without the check now have the check.
Your patch added 85 checks, which is a broad sweep, which is why it was rejected. Repeating myself, if there is any specific place where we get a NULL interface in Windows, then we should have already handled it and done a skip before we ever got to the release. If not, then that handling should be added.
James Hawkins wrote:
On Wed, Oct 8, 2008 at 10:05 PM, Chris Ahrendt celticht32@aol.com wrote:
It was not a broad sweep... I know where it crashed and am checking there. However, I noticed there were several other places were at sometimes it checked for null and other places it did not.. so I went through and made sure all of the ones without the check now have the check.
Your patch added 85 checks, which is a broad sweep, which is why it was rejected. Repeating myself, if there is any specific place where we get a NULL interface in Windows, then we should have already handled it and done a skip before we ever got to the release. If not, then that handling should be added.
Actually it was rejected because Dan's network went down and crashed patchwatcher..
Chris
On Wed, Oct 8, 2008 at 10:12 PM, Chris Ahrendt celticht32@aol.com wrote:
Actually it was rejected because Dan's network went down and crashed patchwatcher..
Alexandre does not receive notices from patchwatcher, nor does he rely on the patchwatcher results when reviewing patches...
James Hawkins wrote:
On Wed, Oct 8, 2008 at 10:12 PM, Chris Ahrendt celticht32@aol.com wrote:
Actually it was rejected because Dan's network went down and crashed patchwatcher..
Alexandre does not receive notices from patchwatcher, nor does he rely on the patchwatcher results when reviewing patches...
I never got a patch rejection so how was I to know? all I knew was patch watcher crashed... the CreateSurface call is the one that is failing... so should the 15494 bug be closed and a new one against CreateSurface be opened then?
chris
On Wed, Oct 8, 2008 at 10:17 PM, Chris Ahrendt celticht32@aol.com wrote:
James Hawkins wrote:
On Wed, Oct 8, 2008 at 10:12 PM, Chris Ahrendt celticht32@aol.com wrote:
Actually it was rejected because Dan's network went down and crashed patchwatcher..
Alexandre does not receive notices from patchwatcher, nor does he rely on the patchwatcher results when reviewing patches...
I never got a patch rejection so how was I to know? all I knew was patch watcher crashed... the CreateSurface call is the one that is failing... so should the 15494 bug be closed and a new one against CreateSurface be opened then?
You can report a new bug if you feel like it, but bug 15494 should be left open until a fix is in. Roderick described what needs to be done in comment #6 of that bug.
James Hawkins wrote:
On Wed, Oct 8, 2008 at 10:17 PM, Chris Ahrendt celticht32@aol.com wrote:
James Hawkins wrote:
On Wed, Oct 8, 2008 at 10:12 PM, Chris Ahrendt celticht32@aol.com wrote:
Actually it was rejected because Dan's network went down and crashed patchwatcher..
Alexandre does not receive notices from patchwatcher, nor does he rely on the patchwatcher results when reviewing patches...
I never got a patch rejection so how was I to know? all I knew was patch watcher crashed... the CreateSurface call is the one that is failing... so should the 15494 bug be closed and a new one against CreateSurface be opened then?
You can report a new bug if you feel like it, but bug 15494 should be left open until a fix is in. Roderick described what needs to be done in comment #6 of that bug.
ok will then start looking into why CreateSurface is having an issue... don't know if I can provide a fix but I can look at debugging it =D
chris
The whole issue is a driver bug (the drmMap issue related to lack of virtual memory caused by Wine). This causes CreateSurface to fail. Though there can also be other reasons why CreateSurface can fail (though not in this case). The test should just for the failure of creating surfaces and then abort if at the start of one of the tests this fails.
Roderick
James Hawkins wrote:
On Wed, Oct 8, 2008 at 10:12 PM, Chris Ahrendt celticht32@aol.com
wrote:
Actually it was rejected because Dan's network went down and crashed patchwatcher..
Alexandre does not receive notices from patchwatcher, nor does he rely on the patchwatcher results when reviewing patches...
I never got a patch rejection so how was I to know? all I knew was patch watcher crashed... the CreateSurface call is the one that is failing... so should the 15494 bug be closed and a new one against CreateSurface be opened then?
chris
-
Chris Ahrendt -
James Hawkins -
Roderick Colenbrander