1211666 - Marionette fails if path to gecko.log does not exist

Status: RESOLVED WONTFIX

(Remote Protocol :: Marionette, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

If you are running Marionette with a path to gecko.log whereby the directory does not exist yet, an exception is thrown:

$ marionette --binary /mozilla/bin/nightly/firefox --gecko-log anz/gecko.log .
Traceback (most recent call last):
  File "/home/henrik/.virtualenvs/fxtests/bin/marionette", line 9, in <module>
    load_entry_point('marionette-client==1.0.0', 'console_scripts', 'marionette')()
  File "/home/henrik/.virtualenvs/fxtests/local/lib/python2.7/site-packages/marionette_client-1.0.0-py2.7.egg/marionette/runtests.py", line 59, in cli
    runner = startTestRunner(runner_class, args)
  File "/home/henrik/.virtualenvs/fxtests/local/lib/python2.7/site-packages/marionette_client-1.0.0-py2.7.egg/marionette/runtests.py", line 38, in startTestRunner
    runner.run_tests(tests)
  File "/home/henrik/.virtualenvs/fxtests/local/lib/python2.7/site-packages/marionette_client-1.0.0-py2.7.egg/marionette/runner/base.py", line 724, in run_tests
    self.start_marionette()
  File "/home/henrik/.virtualenvs/fxtests/local/lib/python2.7/site-packages/marionette_client-1.0.0-py2.7.egg/marionette/runner/base.py", line 669, in start_marionette
    self.marionette = self.driverclass(**self._build_kwargs())
  File "/home/henrik/.virtualenvs/fxtests/local/lib/python2.7/site-packages/marionette_driver-1.0.0-py2.7.egg/marionette_driver/marionette.py", line 595, in __init__
    self.instance.start()
  File "/home/henrik/.virtualenvs/fxtests/local/lib/python2.7/site-packages/marionette_driver-1.0.0-py2.7.egg/marionette_driver/geckoinstance.py", line 120, in start
    self.runner.start()
  File "/home/henrik/.virtualenvs/fxtests/local/lib/python2.7/site-packages/mozrunner/base/browser.py", line 81, in start
    BaseRunner.start(self, *args, **kwargs)
  File "/home/henrik/.virtualenvs/fxtests/local/lib/python2.7/site-packages/mozrunner/base/runner.py", line 103, in start
    self.process_handler = self.process_class(cmd, env=self.env, **self.process_args)
  File "/home/henrik/.virtualenvs/fxtests/local/lib/python2.7/site-packages/mozprocess/processhandler.py", line 979, in __init__
    logoutput = LogOutput(logfile)
  File "/home/henrik/.virtualenvs/fxtests/local/lib/python2.7/site-packages/mozprocess/processhandler.py", line 947, in __init__
    self.file_obj = open(filename, 'a')
IOError: [Errno 2] No such file or directory: '/mozilla/code/firefox-ui-tests/anz/gecko.log'
Exception AttributeError: "'LogOutput' object has no attribute 'file_obj'" in <bound method LogOutput.__del__ of <mozprocess.processhandler.LogOutput object at 0x7fa1335c1b50>> ignored

It might be good to create the directory tree down to the wanted folder name.

Comment 1

[Jalem Raj Rohit (:Dawny33)]

Hi Jonathan,

I want to work on this bug.  Can I please know how do I work on it?

Comment 2

[Jonathan Griffin (:jgriffin)]

Hi Jalem,

First, I suggest you attempt to reproduce the problem. Follow the directions at https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette/Running_Tests, and when you invoke Marionette, add a --gecko-log argument which specifies a file in a directory which does not exist. You should get the error above.

Comment 3

[Jalem Raj Rohit (:Dawny33)]

Jonathan, a small doubt:

I already have the mozilla-central directory at ~/mozilla-central.

So, do I still need to do hg clone http://hg.mozilla.org/mozilla-central/ $GECKO_DIR  ?
If yes, then in which directory?  Inside mozilla-central or in ~ ?

Comment 4

[Jonathan Griffin (:jgriffin)]

You can use your existing mozilla-central clone; just make sure it's up-to-date. Feel free to ping me on irc.mozilla.org (jgriffin on #ateam) if you'd like.

Comment 5

[Jalem Raj Rohit (:Dawny33)]

(In reply to Jonathan Griffin (:jgriffin) from comment #2)
> Hi Jalem,
> 
> First, I suggest you attempt to reproduce the problem. Follow the directions
> at
> https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette/Running_Tests,
> and when you invoke Marionette, add a --gecko-log argument which specifies a
> file in a directory which does not exist. You should get the error above.


Error reproduced when invoking marionette on a file/directory which does not exist  (http://pastebin.com/hANwn2i8)

Comment 6

[Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me)]

I've been chatting with :Dawny33 on IRC. My suggestion for how to tackle this bug is to add a case for creating the directory tree down to the wanted folder name somewhere in here: https://dxr.mozilla.org/mozilla-central/source/testing/marionette/driver/marionette_driver/geckoinstance.py#63

Comment 7

[Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me)]

There's been no activity here for a month, so I am un-assigning the bug. 

Jalem -- if you intend to work on this just let us know by adding a comment. :) Hope to see you soon, best wishes.

Comment 8

[Shivin]

Hi I would like to work on this bug can you guys give me an over review on how I can start tackling the bug 
-Thanks

Comment 9

[Andreas Tolfsen ❲:ato❳]

I’m actually not convinced it’s a good idea to create the directory tree, and I cannot think of many programs in existing literature that does this.  It sounds like a source of potential future problems because you can’t be sure which user the Python process runs under, or if it will give your newly created directory hierarchy the correct permissions.

In my opinion the current behaviour is not that surprising at all: The file you’re giving can’t be written to because the location doesn’t exist.

Comment 10

[Shivin]

(In reply to Andreas Tolfsen (:ato) from comment #9)
> I’m actually not convinced it’s a good idea to create the directory tree,
> and I cannot think of many programs in existing literature that does this. 
> It sounds like a source of potential future problems because you can’t be
> sure which user the Python process runs under, or if it will give your newly
> created directory hierarchy the correct permissions.
> 
> In my opinion the current behaviour is not that surprising at all: The file
> you’re giving can’t be written to because the location doesn’t exist.

so is there no valid way to solve the bug because permission inavailability can not really be solved in this script

Comment 11

[Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me)]

I'm removing the good-first-bug flag until there's agreement about a solution.

Comment 12

[Jonathan Griffin (:jgriffin)]

Based on comment #9, I think we should just close as WONTFIX.