Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nixos: tests: firefox: make more comprehensive #23924

Merged
merged 1 commit into from Mar 17, 2017

Conversation

7c6f434c
Copy link
Member

Run Firefox inside an XTerm, it doesn't crash mysteriously this way.
Also try opening developer tools and checking that Firefox doesn't
crash in the process.

Motivation for this change

In #23917 there is a Firefox crash that happens all the time but cannot be reproduced manually. The workaround for this crash makes the build that crashes on every keypress pass the test, so I added a check that developer tools can be opened.

Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • Linux
  • Opened the resulting screenshot

@mention-bot
Copy link

@7c6f434c, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @peti and @chaoflow to be potential reviewers.

@vcunat
Copy link
Member

vcunat commented Mar 15, 2017

Certainly 👍 for the xterm change to unblock channel for now.

It would be nice if we could somehow detect the process dying instead of blocking on waitForWindow indefinitely, but I consider that future work.

The space key is meant to test scrolling, or am I missing something? It seems this small page is likely to fit into the window.

@7c6f434c
Copy link
Member Author

No. The browser asks whether to make it the default browser with probability around 90%, the default option — we do not care which one — should not crash, and we need to close this window to be able to send events to the real browser window. If by any chance the browser does not ask to make itself the default — then space is probably interpreted as scrolling, no harm done. When we see the situation where both guesses are wrong and something bad happens, we investigate it…

@vcunat
Copy link
Member

vcunat commented Mar 15, 2017

Oh, I forgot that thing :-) I didn't get what "default browser window" meant (parenthesized the other way).

@7c6f434c
Copy link
Member Author

@vcunat by the way, the channel is blocked until you merge at least the xterm hack. On the other hand, it doesn't matter until the fixed Firefox is actually built, but that build is hopefully less than an hour.

@7c6f434c
Copy link
Member Author

Added a more detailed comment. The test is a scarily good model of user behaviour in this place!

@vcunat
Copy link
Member

vcunat commented Mar 15, 2017

I know that, but just patching ICU is a nontrivial rebuild by itself AFAIK.

Run Firefox inside an XTerm, it doesn't crash mysteriously this way.
Also try opening developer tools and checking that Firefox doesn't
crash in the process.
@7c6f434c
Copy link
Member Author

Ah you are right, the test is fast to run and there will be a lot of other contenders for build slots.

@vcunat
Copy link
Member

vcunat commented Mar 15, 2017

Oh, no. trunk-combined eval is repeatedly throwing

hydra-eval-jobs returned signal 6:
Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS

and consequently hasn't had a successful evaluation for two days. EDIT: at least plain trunk jobset evaluated now, after a few attempts...

@7c6f434c
Copy link
Member Author

Oh, ICU update means Freetype rebuild, right.

@vcunat
Copy link
Member

vcunat commented Mar 15, 2017

No, freetype has the same derivation hash.

@vcunat
Copy link
Member

vcunat commented Mar 15, 2017

It seems especially big on Darwin.

@vcunat
Copy link
Member

vcunat commented Mar 15, 2017

... which is because their stdenv depends on it (news for me).

$machine->waitForWindow(qr/Valgrind/);
$machine->sleep(40); # wait until Firefox has finished loading the page
$machine->execute("xdotool key space"); # do I want to make Firefox the
# default browser? I just want to close the dialog
Copy link
Member

@Mic92 Mic92 Mar 16, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just an off-topic question, how do you debug the test driver? I tried to unbrick gdm test, but I have no idea in what state the desktop is.

@7c6f434c
Copy link
Member Author

7c6f434c commented Mar 16, 2017 via email

@7c6f434c
Copy link
Member Author

OK, no negative feedback and a hope to unblock the channel. I merge.

@7c6f434c 7c6f434c merged commit f9fb38f into NixOS:master Mar 17, 2017
@vcunat
Copy link
Member

vcunat commented Mar 17, 2017

trunk-combined still can't be evaluated by Hydra, so this won't be enough, I'm afraid.

vcunat pushed a commit that referenced this pull request Mar 17, 2017
nixos: tests: firefox: make more comprehensive

(cherry picked from commit f9fb38f)
The test will block the channel without the xterm change.
@7c6f434c
Copy link
Member Author

7c6f434c commented Mar 17, 2017 via email

@globin
Copy link
Member

globin commented Mar 22, 2017

@vcunat
Copy link
Member

vcunat commented Mar 22, 2017

The log... I wondered why logs disappeared from hydra.nixos.org - but I can't determine how to read the log URL you provided. It's not plaintext and I can't detect any common compression.

@7c6f434c
Copy link
Member Author

And content type is text/plain — that's just not true…

@vcunat
Copy link
Member

vcunat commented Mar 22, 2017

That's some other problem:

machine# [    5.085679] display-manager[812]: (WW) Falling back to old probe method for modesetting
machine# [    5.086332] display-manager[812]: (EE) open /dev/dri/card0: No such file or directory
machine# [    5.086982] display-manager[812]: (EE) Screen 0 deleted because of no matching config section.
machine# [    5.087667] display-manager[812]: (II) UnloadModule: "modesetting"
machine# [    5.088207] display-manager[812]: (EE) Device(s) detected, but none match those in the config file.
machine# [    5.088881] display-manager[812]: (EE)
machine# [    5.089278] display-manager[812]: Fatal server error:
machine# [    5.089747] display-manager[812]: (EE) no screens found(EE)
machine# [    5.090261] display-manager[812]: (EE)
machine# [    5.090672] display-manager[812]: Please consult the The X.Org Foundation support
machine# [    5.091238] display-manager[812]:    at http://wiki.x.org
machine# [    5.091743] display-manager[812]:  for help.
machine# [    5.092154] display-manager[812]: (EE) Please also check the log file at "/dev/null" for additional information.
machine# [    5.092876] display-manager[812]: (EE)
machine# [    5.093309] display-manager[812]: (EE) Server terminated with error (1). Closing log file.

@globin
Copy link
Member

globin commented Mar 22, 2017

@vcunat breaks in firefox, works in chromium 🤷‍♂️

@vcunat
Copy link
Member

vcunat commented Mar 22, 2017

It also works in firefox on 17.03 (it includes this PR).

@7c6f434c
Copy link
Member Author

7c6f434c commented Mar 22, 2017

Fails in chromium on master for me. i3wm.nix test is also unhappy. Seems to be a non-specific problem…

Edited to add: gnome3.nix — which is likely fresher — also fails.

@vcunat
Copy link
Member

vcunat commented Mar 22, 2017

OK, let my try to bisect this on i3wm (it's lighter). It will take some time, as Hydra evaluations were blocked for several days and the potential interval is long.

@vcunat
Copy link
Member

vcunat commented Mar 22, 2017

The culprit is 0c262a6; discussion: #23890 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants