Bug 100408 - REGRESSION (r132328): /WebKit2APITests/TestWebKitAccessibility unit test is failing
Summary: REGRESSION (r132328): /WebKit2APITests/TestWebKitAccessibility unit test is f...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk
Depends on:
Blocks:
 
Reported: 2012-10-25 13:08 PDT by Zan Dobersek
Modified: 2013-09-04 06:30 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zan Dobersek 2012-10-25 13:08:45 PDT
The TestWebKitAccessibility unit test has been failing after the run-gtk-tests script was modified in r132328.
http://trac.webkit.org/changeset/132328

I'll skip the test for now.
Comment 1 Zan Dobersek 2012-10-25 13:10:33 PDT
Of course, I should give some more information about the failing test.
Here's the output:

TEST: ./Tools/gtk/../Scripts/../../WebKitBuild/Release/Programs/WebKit2APITests/TestWebKitAccessibility... (pid=12069)

failed to create drawable

  /webkit2/WebKitAccessibility/atspi-basic-hierarchy:                  **

ERROR:../../Source/WebKit2/UIProcess/API/gtk/tests/TestWebKitAccessibility.cpp:136:void checkAtspiAccessible(AtspiAccessible*, const char*, AtspiRole): assertion failed (targetRole == atspi_accessible_get_role(accessible, 0)): (23 == 0)

FAIL
Comment 2 Mario Sanchez Prada 2012-10-26 07:02:16 PDT
(In reply to comment #1)
> Of course, I should give some more information about the failing test.
> Here's the output:
> 
> TEST: ./Tools/gtk/../Scripts/../../WebKitBuild/Release/Programs/WebKit2APITests/TestWebKitAccessibility... (pid=12069)
> 
> failed to create drawable

This doesn't seem to me like a fail in the test but in the environment in the buildbot. Actually, I have just logged in the buildbot, run the test and it works fine, so maybe we should unskip it again and give it another shot.

What do you think?

>   /webkit2/WebKitAccessibility/atspi-basic-hierarchy:                  **
> 
>ERROR:../../Source/WebKit2/UIProcess/API/gtk/tests/TestWebKitAccessibility.cpp:1
> 36:void checkAtspiAccessible(AtspiAccessible*, const char*, AtspiRole): 
> assertion failed (targetRole == atspi_accessible_get_role(accessible, 0)): 
> (23 == 0)
> 

Couldn't reproduce this, neither in the bots neither locally (and I have tried both with Release and Debug builds, right after updating my local repo this morning)
Comment 3 Mario Sanchez Prada 2012-10-26 07:04:24 PDT
(In reply to comment #2)
> (In reply to comment #1)
> > Of course, I should give some more information about the failing test.
> > Here's the output:
> > 
> > TEST: ./Tools/gtk/../Scripts/../../WebKitBuild/Release/Programs/WebKit2APITests/TestWebKitAccessibility... (pid=12069)
> > 
> > failed to create drawable
> 
> This doesn't seem to me like a fail in the test but in the environment in the 
> buildbot. Actually, I have just logged in the buildbot, run the test and it 
> works fine, so maybe we should unskip it again and give it another shot.

Hmmm.. one clarification: I tried running this in the normal buildbots, not in the WebKit2 one (no idea how to try it out there). Maybe Sergio (added to CC) could help us with that? 

JFTR, I'd just run this command:

$ Tools/Scripts/run-gtk-tests \
     WebKitBuild/Release/Programs/WebKit2APITests/TestWebKitAccessibility
Comment 4 Sergio Villar Senin 2012-11-13 17:07:02 PST
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Of course, I should give some more information about the failing test.
> > > Here's the output:
> > > 
> > > TEST: ./Tools/gtk/../Scripts/../../WebKitBuild/Release/Programs/WebKit2APITests/TestWebKitAccessibility... (pid=12069)
> > > 
> > > failed to create drawable
> > 
> > This doesn't seem to me like a fail in the test but in the environment in the 
> > buildbot. Actually, I have just logged in the buildbot, run the test and it 
> > works fine, so maybe we should unskip it again and give it another shot.
> 
> Hmmm.. one clarification: I tried running this in the normal buildbots, not in the WebKit2 one (no idea how to try it out there). Maybe Sergio (added to CC) could help us with that? 

Not sure what you mean Mario, the WK2 behaves exactly the same as any other bot, the difference is that we just copy the WebKitBuild/Release folder there instead of generating it in the bot. There should be no difference.
Comment 5 Mario Sanchez Prada 2012-11-15 04:07:33 PST
(In reply to comment #4)
> [...]
> Not sure what you mean Mario, the WK2 behaves exactly the same as any other 
> bot, the difference is that we just copy the WebKitBuild/Release folder there 
> instead of generating it in the bot. There should be no difference.

I just meant that I was not able to try it in the WK2 and so that I could not be sure whether there could be any (subtle?) difference explaining why it worked in the non-WK2 bots but not in the other one.

If you (or anyone else with access to the WK2 bot) could try this out that would be of great help I think.
Comment 6 Mario Sanchez Prada 2013-09-04 04:05:04 PDT
(In reply to comment #5)
> (In reply to comment #4)
> > [...]
> > Not sure what you mean Mario, the WK2 behaves exactly the same as any other 
> > bot, the difference is that we just copy the WebKitBuild/Release folder there 
> > instead of generating it in the bot. There should be no difference.
> 
> I just meant that I was not able to try it in the WK2 and so that I could not be sure whether there could be any (subtle?) difference explaining why it worked in the non-WK2 bots but not in the other one.
> 
> If you (or anyone else with access to the WK2 bot) could try this out that would be of great help I think.

I've just talked to Sergio again now and he confirms that running this test directly in the WK2 is working fine now, so we believe we can give it a try and unskip it.
Comment 7 Mario Sanchez Prada 2013-09-04 06:30:14 PDT
Committed r155038: <http://trac.webkit.org/changeset/155038>