Last Comment Bug 536015 - 'WINNT 5.2 comm-central-trunk build' times out while running 'nss/shlibsign', due to missing renamed sqlite3.dll
: 'WINNT 5.2 comm-central-trunk build' times out while running 'nss/shlibsign',...
Status: VERIFIED FIXED
[Fixed by clobbering]
: regression
Product: SeaMonkey
Classification: Client Software
Component: Build Config (show other bugs)
: Trunk
: x86 Windows Server 2003
: -- major (vote)
: seamonkey2.1a1
Assigned To: Robert Kaiser (not working on stability any more)
:
Mentors:
Depends on: 513747
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-19 18:23 PST by Serge Gautherie (:sgautherie)
Modified: 2009-12-20 08:57 PST (History)
2 users (show)
bugzillamozillaorg_serge_20140323: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Serge Gautherie (:sgautherie) 2009-12-19 18:23:57 PST
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey&maxdate=1261230389&hours=24&legend=0&norules=1
moz:d303e54445e7 was fine.
moz:eeba84d24038 went red because of bug 524944 landing.
moz:f6f1982d758d fixed that bustage. But this bug appeared.

Firefox, Thunderbird and 'WINNT 5.2 comm-central-trunk nightly' are green.

Maybe a stuck file/process? Or this tree needs a clobber? ...
Comment 1 Robert Kaiser (not working on stability any more) 2009-12-19 18:29:46 PST
This must be a code failure - it happens on all machines, and actually started right _after_ I clobbered dist/ on them.
Comment 2 Robert Kaiser (not working on stability any more) 2009-12-19 19:53:32 PST
And here's a good hint of what's up there - an error message shown on 3 of the 4 machines:

shlibsign.exe - Unable To Locate Component
The application has failed to start because sqlite3.dll was not found. Re-installing the application may fix this problem.
Comment 3 Robert Kaiser (not working on stability any more) 2009-12-19 19:58:40 PST
Sounds to me like something else caused by bug 513747 but maybe hidden until we clobbered dist/ on the machines.

I completely clobbered objdir on the machines to be sure, but I think very much that this is related to the sqlite renaming.
Comment 4 Serge Gautherie (:sgautherie) 2009-12-19 20:05:36 PST
["Mid-air collision detected!", posting anyway, ftr.]

(In reply to comment #0)

Regression timeframe:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d303e54445e7&tochange=f6f1982d758d
Nothing obvious to me. (but see below)

(In reply to comment #1)
> This must be a code failure - it happens on all machines, and actually started
> right _after_ I clobbered dist/ on them.

(Well, I couldn't guess that, as it's not noted on the waterfall...)
Maybe the clobber triggered this failure somehow:
if it's a code issue, it might be from an older changeset :-/
Comment 5 Serge Gautherie (:sgautherie) 2009-12-19 20:25:49 PST
(In reply to comment #3)

> Sounds to me like something else caused by bug 513747 but maybe hidden until we
> clobbered dist/ on the machines.

Maybe, yes.
It even looks like it could be related to bug 519550...

> I completely clobbered objdir on the machines to be sure, but I think very much
> that this is related to the sqlite renaming.

Worth trying, though I wonder why it fails on this tree only and nowhere else :-<
(I mean, at least Firefox does automatic clobber, doesn't it?)
Comment 6 Robert Kaiser (not working on stability any more) 2009-12-20 06:21:05 PST
Looks like the complete clobber of the objdir helped in the end, all machines came back green after all - and yes, I vaguely remember that Firefox needed a clobber there as well - I guess the Windows build chain has a problem finding out about changed dependencies...
Comment 7 Serge Gautherie (:sgautherie) 2009-12-20 08:56:45 PST
Yeah, both bugs were pushed with a clobber:
see bug 513747 comment 87 for example.

V.Fixed, per tinderbox.

Note You need to log in before you can comment on or make changes to this bug.