Bugzilla

Comment 4

•

14 years ago

Don't understand where this is coming from. Both VMs and the hardware are running 'Xvfb :2 -screen 0 1280x1024x24' and 'metacity --display :2 --replace' and test with 'DISPLAY=:2' in the environment.

Comment 5

•

14 years ago

Pulled ix slaves 02,03, 05-10, 12-25 from production to give bear time to get his vpn on. Idle slaves had buildbot stopped, busy slaves will not start buildbot after their current job is done. Renamed buildbot.tac to buildbot.tac.off to effect this. Slave 11 has other problems, bug 546424. Still working on 4.

Comment 6

•

14 years ago

mv-moz2-linux-ix-slave04 is supposed to be in an reboot loop, for bug 546424 again, and 01 is permanently in staging so thats all of them.

Comment 7

•

14 years ago

I've done the following mv-moz2-linux-ix-slave02,03,05-08 (as cltbld via ssh):

rm -rf /builds/slave/*/ &
su - -c 'rsync -av --delete ~cltbld/.ssh_staging/ ~cltbld/.ssh/'
# enter root password

sed -i -e "s/production-master.*/staging-master.build.mozilla.org\'/" \
  /builds/slave/buildbot.tac.off
fg

# wait for rm to finish
mv /builds/slave/buildbot.tac{.off,}
buildbot start /builds/slave

Still to do mv-moz2-linux-ix-slave09,10,12-25.

Comment 8

•

14 years ago

Went ahead and did mv-moz2-linux-ix-slave09,10,12,14-25. That's everything between 01 and 25 except:
* mv-moz2-linux-ix-slave04 and 11 for bug 546424 (grub issues)
* mv-moz2-linux-ix-slave13 I couldn't log in to, perhaps the temp passwords used by the suppliers ?

To do:
* convert slave13 to staging
* figure out why test_largemenu.xul and friends are failing

Assignee

Updated

•

14 years ago

No longer depends on: 549722

Assignee

Updated

•

14 years ago

Assignee: bear → bhearsum

Assignee

Comment 9

•

14 years ago

(In reply to comment #8)
> * convert slave13 to staging

The filesystem was in rough shape for some reason, actually. It was fine after fscking. It's back in staging now.

> * figure out why test_largemenu.xul and friends are failing

I started looking into this. So far I've run it by hand while watching over VNC. It looks fine from there. The window is exactly the same size as it is on a VM.

I set an alert() to happen shortly after one of the pop-ups in this test and *that* window is the same size on a VM and ix machine, too.

I've also verified that all the same versions of X, GTK, et. al are installed on both, and they are.

At this point it would be really helpful to have some developer support here. I'm not sure how to go about debugging this test.

Neil, if I give you access to an environment where this test fails could you help me debug it?

Neil Deakin

Comment 10

•

14 years ago

Is the test being run on a machine with differing screen characteristics - more than one, different resolution, depth, etc? What OS UI is visible (taskbars)?

I can debug it if you'd like.

Assignee

Comment 11

•

14 years ago

(In reply to comment #10)
> Is the test being run on a machine with differing screen characteristics - more
> than one, different resolution, depth, etc? What OS UI is visible (taskbars)?

Both the VM (which passes the test) and the full-hardware machine (which fails) are the same. Here's a dump from xdpyinfo:
screen #0:
  dimensions:    1280x1024 pixels (325x260 millimeters)
  resolution:    100x100 dots per inch
  depths (7):    1, 4, 8, 16, 24, 32, 24
  root window id:    0x40
  depth of root window:    24 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x20
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 16777215
  options:    backing-store NO, save-unders NO
  largest cursor:    1280x1024

> I can debug it if you'd like.

That'd be great -- I'll catch you on IRC to hook you up with access to the machine.

Assignee

Comment 12

•

14 years ago

I caught up with Enn over IRC and we're currently working on getting him access to a machine this fails on.

Assignee

Updated

•

14 years ago

Depends on: 551476

Assignee

Comment 13

•

14 years ago

From IRC:
15:16 <Enn> ok, I think the problem is that popups are being moved 
            asyncronously on linux. may be related to bug 472675
15:16 <Enn> works ok if I put some timers in

Assignee

Comment 14

•

14 years ago

To sum up the status here:

> http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1267548048.1267549160.19480.gz
> Linux mozilla-central opt test mochitest-other on 2010/03/02 08:40:48
> s: mv-moz2-linux-ix-slave03
> 7727 ERROR TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/chrome/toolkit/content/tests/chrome/test_largemenu.xul
> | context menu more space above top - got -778, expected -344
> 7729 ERROR TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/chrome/toolkit/content/tests/chrome/test_largemenu.xul

Working with Enn to find a fix for these tests.

> | context menu too big either side top
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_354894.js
> | browser windows while running testOpenCloseRestoreFromPopup (getBrowserState)
> - Got 2, expected 1
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_354894.js
> | browser windows after testOpenCloseRestoreFromPopup (getBrowserState) - Got
> 2, expected 1
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_354894.js
> | browser windows after testNotificationCount (getBrowserState) - Got 2,
> expected 1
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_394759.js
> | oldState in test_purge has 2 windows instead of 1
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_394759.js
> | number of browser windows after test_purge - Got 2, expected 1
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_394759.js
> | Found an unexpected browser window at the end of test run
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_394759_privatebrowsing.js
> | Found an unexpected browser window at the end of test run
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_394759_privatebrowsing.js

All of these files are mentioned in two existing bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=518970 and https://bugzilla.mozilla.org/show_bug.cgi?id=528219.

> | Found an unexpected browser window at the end of test run
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_522545.js
> | Only one browser window should be open eventually - Got 5, expected 1
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_522545.js
> | Found an unexpected browser window at the end of test run
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_522545.js
> | Found an unexpected browser window at the end of test run
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_522545.js
> | Found an unexpected browser window at the end of test run
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_522545.js

This file has other bugs filed on it, some of which talk about timing problems. Might be the case for this, too:
https://bugzilla.mozilla.org/show_bug.cgi?id=528699
https://bugzilla.mozilla.org/show_bug.cgi?id=537061

> | Found an unexpected browser window at the end of test run
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_528776.js
> | number of open browser windows according to getBrowserState - Got 9, expected
> 1
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_528776.js
> | number of open browser windows according to getBrowserState - Got 10,
> expected 2
> TEST-UNEXPECTED-FAIL |
> chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_528776.js
> | number of open browser windows according to getBrowserState - Got 9, expected
> 1

Can't find anything on this one.

Summary: Linux ix machines failing test_largemenu.xul and others every time → Linux ix machines failing many unit tests every time

Comment 15

•

14 years ago

One failure chunk here is bug 518970.  This is perfect, in that we now have a 100% reproducible failure here.  :-)

Depends on: 518970

Comment 16

•

14 years ago

(In reply to comment #15)
> One failure chunk here is bug 518970.  This is perfect, in that we now have a
> 100% reproducible failure here.  :-)

I found and fixed the problem with bug 518970.  That part won't be an issue here after my patch in that bug lands.

Neil Deakin

Comment 17

•

14 years ago

Attached patch fix largemenu test by waiting for window to move in a loop. — Details — Splinter Review

Assignee

Comment 18

•

14 years ago

(In reply to comment #17)
> Created an attachment (id=432160) [details]
> fix largemenu test by waiting for window to move in a loop.

This patch seems to fix the failure

Assignee

Updated

•

14 years ago

Attachment #432160 - Flags: checked-in+

Assignee

Comment 19

•

14 years ago

Comment on attachment 432160 [details] [diff] [review]
fix largemenu test by waiting for window to move in a loop.

1.9.2 landing: changeset:   33731:ddc086030f76

m-c landing: changeset:   39361:e0d293fe8408


Need to backport to 1.9.1 still, this patch didn't apply cleanly there.

Comment 20

•

14 years ago

Ben, can you please grab a fresh build from m-c and see if it passes all the tests on this machine now?

Assignee

Comment 21

•

14 years ago

(In reply to comment #20)
> Ben, can you please grab a fresh build from m-c and see if it passes all the
> tests on this machine now?

Will do in a bit

Assignee

Comment 22

•

14 years ago

(In reply to comment #19)
> (From update of attachment 432160 [details] [diff] [review])
> 1.9.2 landing: changeset:   33731:ddc086030f76
> 
> m-c landing: changeset:   39361:e0d293fe8408
> 
> 
> Need to backport to 1.9.1 still, this patch didn't apply cleanly there.

Turns out we don't fail on 1.9.1, so we don't need to bother with this.



Ehsan, chrome and browser-chrome tests fully pass on m-c now!

Comment 23

•

14 years ago

So, should this be FIXED now?

Assignee

Comment 24

•

14 years ago

(In reply to comment #23)
> So, should this be FIXED now?

I'm going to wait until the patch in https://bugzilla.mozilla.org/show_bug.cgi?id=518970 lands on 1.9.1 and 1.9.2 first, actually.

Comment 25

•

14 years ago

(In reply to comment #24)
> (In reply to comment #23)
> > So, should this be FIXED now?
> 
> I'm going to wait until the patch in
> https://bugzilla.mozilla.org/show_bug.cgi?id=518970 lands on 1.9.1 and 1.9.2
> first, actually.

I landed the patc for bug 518970 on both 1.9.1 and 1.9.2.