562663 - Rev3 Fedora 12 x64 permaorange: chrome://mochikit/content/browser/browser/components/places/tests/browser/browser_library_panel_leak.js

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Armen [:armenzg]]

Now that we have more greeness we can see more specific oranges.

This bug only affects the 64 bit machines.
http://brasstacks.mozilla.com/topfails/test/Firefox?name=chrome://mochikit/content/browser/browser/components/places/tests/browser/browser_library_panel_leak.js

Last 32 bit failure was 2010/04/28 19:12:37 after bug had landed.
 2010-04-28 21:12 Firefox Linux   [60e85e58fd78] 
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1272507157.1272508111.16728.gz

Assigning to Marco per request. Let me know if you need access to a Fedora 64 bit machine.

Comment 1

[Marco Bonardo [:mak]]

i thought i had posted here.
The strange fact is that this happens only on these machines, i could guess some reason for the failure, but all of those would be valid for any platform.

Either: we don't have a selection in the Library, we check it too early (some part is lazy initialized) or the Library is messed up due to a previous test.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The full error from the log is:

TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/components/places/tests/browser/browser_library_panel_leak.js | Editing a bookmark - Didn't expect -1, but got it

I see the exact same thing on 64-bit Ubuntu.

Comment 3

[Marco Bonardo [:mak]]

hm, then i should probably create a local Ubuntu 64 bit VM box.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I don't think it's because something is messed up due to a previous test, since I see the failure if I run the test alone with no other tests.

Comment 5

[Marco Bonardo [:mak]]

Cool, actually i'm fighting with VMWare Workstation 7 that does not want to let me install Ubuntu 10.4 64...
Can you check if you see a selected row in Library, I guess opening the library should just work

Comment 6

[Marco Bonardo [:mak]]

I figured out the problem with Ubuntu, I'm proceeding with install and I should be able to test soon.

Comment 7

[Marco Bonardo [:mak]]

Attachment: patch v1.0

This fixes the test on Ubuntu 64 for me, the edit bookmark overlay is initialized when the element in tree has been focused, that happens after the window is opened, thus I guess this system is fast enough to check too early or focus is handled in a more lazy way. Btw, waiting for proper initialization should be fine.

Comment 8

[Marco Bonardo [:mak]]

PS: sorry for late but I was unable to build libxul.so, it was churning on disk infinitely, till I tried to bump up VM memory from 512MB to 1GB, and that made the trick :(

Comment 9

[Dietrich Ayala (:dietrich)]

Comment on attachment 444369 [details] [diff] [review]
patch v1.0

r=me since this is a test. this is still pretty hacky though. is there not a deterministic way for us to listen for this?

Comment 10

[Marco Bonardo [:mak]]

we could try with waitForFocus, but that's still bogus, and it cannot ensure the overlay object is properly initialized still.

Comment 11

[Marco Bonardo [:mak]]

Armen, can you try if this patch solves the issue on Fedora please?

Comment 12

[Armen [:armenzg]]

I will see if I can give it a whirl sometime this week (I just got the windows unit tests handed off).

If I get you access to the machine do you think you could give a try?

The following link is just for reference to see when was the last time the test fails (once we land it):
http://brasstacks.mozilla.com/topfails/test/Firefox?name=chrome://mochikit/content/browser/browser/components/places/tests/browser/browser_library_panel_leak.js

Comment 13

[Marco Bonardo [:mak]]

Well, I guess I could just land and we check how the boxes reply to that?

Accessing to the box from the other side of the ocean does not look much sane with current bandwidth issues.

Comment 14

[Armen [:armenzg]]

(In reply to comment #13)
> Well, I guess I could just land and we check how the boxes reply to that?
> 
That should work for me. I so wish we had Linux64 try + unit tests (I hope we have it in June).

Comment 15

[Marco Bonardo [:mak]]

http://hg.mozilla.org/mozilla-central/rev/7ae8a656ffe9

I'm resolving for now, if we don't see a change we can reopen, but let's be optimist :)

Comment 16

[Legacy TBPL/Treeherder Robot]

armenzg%mozilla.com
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1273634514.1273636051.19358.gz
Rev3 Fedora 12 mozilla-central opt test mochitest-other, Started 20:21, finished 20:48, took 27mins

s: talos-r3-fed-012
PROCESS-CRASH | automation.py | application crashed (minidump found)
Thread 1 (crashed)
PROCESS-CRASH | automation.py | application crashed (minidump found)
Thread 1 (crashed)
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/components/places/tests/browser/browser_library_panel_leak.js | Editing a bookmark - Didn't expect -1, but got it
TEST-UNEXPECTED-FAIL | automation.py | application timed out after 330 seconds with no output
PROCESS-CRASH | automation.py | application crashed (minidump found)
Thread 0 (crashed)

Comment 17

[Marco Bonardo [:mak]]

comment 16 is prior to the fix.