Bug 49164 - [NRWT] If the http lock fails we shouldn't do any locking
Summary: [NRWT] If the http lock fails we shouldn't do any locking
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 48053
  Show dependency treegraph
 
Reported: 2010-11-08 01:04 PST by Gabor Rapcsanyi
Modified: 2010-11-08 11:03 PST (History)
7 users (show)

See Also:


Attachments
proposed patch (3.18 KB, patch)
2010-11-08 01:23 PST, Gabor Rapcsanyi
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gabor Rapcsanyi 2010-11-08 01:04:26 PST
If something go wrong with the locking, the test should keep going.
Now if it can't create the lock it waits indefinitely.
Comment 1 Gabor Rapcsanyi 2010-11-08 01:23:04 PST
Created attachment 73224 [details]
proposed patch

I put some error check into http_lock.py:
  - lock directory existence check
  - time limit for lock creation
Comment 2 Csaba Osztrogonác 2010-11-08 08:13:42 PST
Comment on attachment 73224 [details]
proposed patch

It is a good workaround to find why the Chromium Windows bot fails when we make http locking default.
Let's watch the bot!
Comment 3 Csaba Osztrogonác 2010-11-08 08:28:46 PST
Landed in http://trac.webkit.org/changeset/71525
Comment 4 Csaba Osztrogonác 2010-11-08 09:09:29 PST
We catched it:

2010-11-08 08:43:35,744 http_lock.py:125  DEBUG Lock does not created: (<type 'exceptions.OSError'>, OSError(17, 'File exists'), <traceback object at 0x026D7418>)
2010-11-08 08:43:35,744 http_lock.py:132  DEBUG Warning, http locking failed!
2010-11-08 08:43:35,744 dump_render_tree_thread.py:545  DEBUG Starting HTTP server ...

---

It means that _guard_lock_file (WebKit.lock) already exists, because 
it was probably left during previous tries of enabling this feature.

One of you Chromium guys, could you remove WebKit.lock file in tempfile.gettempdir() to make http locking work on Chromium-Win bots? 
- "Chromium Win Release (Tests)" bot on build.webkit.org
- "Webkit Win" bot on http://build.chromium.org/p/chromium.webkit/waterfall

But of course it isn't the perfect way to avoid this problem in the future.

---
in def _create_lock_file(self):
    sequential_guard_lock = os.open(self._guard_lock_file, os.O_CREAT | os.O_EXCL)
---

This kind of locking will always fail when a WebKit.lock is stucked for some reason. (e.g. script crashes before unlinking the lock file) I prefer a similar way as in httpd.pm, which always open the lock file and then try to grab the exclusive lock for it:

while (!(open(SEQUENTIAL_GUARD_LOCK, ">$exclusiveLockFile") && flock(SEQUENTIAL_GUARD_LOCK, LOCK_EX|LOCK_NB))) {}
Comment 5 Tony Chang 2010-11-08 11:03:09 PST
(In reply to comment #4)
> One of you Chromium guys, could you remove WebKit.lock file in tempfile.gettempdir() to make http locking work on Chromium-Win bots? 
> - "Chromium Win Release (Tests)" bot on build.webkit.org
> - "Webkit Win" bot on http://build.chromium.org/p/chromium.webkit/waterfall

I deleted the file on the WebKit Win bot on the chromium waterfall.  dglazkov can remove the file (I found it in c:\Documents and Settings\chrome-bot\Local Settings\Temp\) on Chrome Win Release (Tests).