WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
49164
[NRWT] If the http lock fails we shouldn't do any locking
https://bugs.webkit.org/show_bug.cgi?id=49164
Summary
[NRWT] If the http lock fails we shouldn't do any locking
Gabor Rapcsanyi
Reported
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.
Attachments
proposed patch
(3.18 KB, patch)
2010-11-08 01:23 PST
,
Gabor Rapcsanyi
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Gabor Rapcsanyi
Comment 1
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
Csaba Osztrogonác
Comment 2
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!
Csaba Osztrogonác
Comment 3
2010-11-08 08:28:46 PST
Landed in
http://trac.webkit.org/changeset/71525
Csaba Osztrogonác
Comment 4
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))) {}
Tony Chang
Comment 5
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).
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug