Bug 39197 – failing to link WebKit on win-ews machine (32-bit windows, Visual Studio Express)

• Component: Tools / Tests
• Status: RESOLVED WORKSFORME

[Eric Seidel (no email)]

failing to link WebKit on win-ews machine (32-bit windows, Visual Studio Express)

	 	
Performing Pre-Build Event...
/usr/bin/bash
cl : Command line warning D9040 : ignoring option '/analyze'; Code Analysis warnings are not available in this edition of the compiler
tmp.cpp
File not found - *
0 File(s) copied
Linking...
LINK : fatal error LNK1102: out of memory
Project : warning PRJ0018 : The following environment variables were not found:
$(PRODUCTION)
$(DXSDK_DIR)
Build machine environment variables may not be correct.

At least I think this is the error which is causing the build to fail.

[Adam Roben (:aroben)]

This sounds like bug 32516.

[Eric Seidel (no email)]

It does sound similar, however the win-ews was able to build until recently.  Checking the win-ews status logs (from webkit-commit-queue.appspot.com), the first failure occurred between 7pm  5/11/10 and 7am 5/11/10.

	id=2185135	 <null>	 <null>	 <null>	 2010-05-12 07:20:14.302495	 Unable to perform a build	 win-ews
	id=2165155	 36335	 55671	 <null>	 2010-05-11 19:02:56.111023	 Error: Failed to run "[u'/mnt/svn/webkit-win-ews/WebKitTools/Scripts/svn-apply', u'--force']" exit_code: 1	 win-ews
	id=2203133	 38885	 55669	 <null>	 2010-05-11 18:01:54.537281	 Pass	 win-ews

[Adam Roben (:aroben)]

(In reply to comment #2)
> It does sound similar, however the win-ews was able to build until recently.  Checking the win-ews status logs (from webkit-commit-queue.appspot.com), the first failure occurred between 7pm  5/11/10 and 7am 5/11/10.
> 
>     id=2185135     <null>     <null>     <null>     2010-05-12 07:20:14.302495     Unable to perform a build     win-ews
>     id=2165155     36335     55671     <null>     2010-05-11 19:02:56.111023     Error: Failed to run "[u'/mnt/svn/webkit-win-ews/WebKitTools/Scripts/svn-apply', u'--force']" exit_code: 1     win-ews
>     id=2203133     38885     55669     <null>     2010-05-11 18:01:54.537281     Pass     win-ews

If I'm reading this correctly, this seems most likely to place the blame on r55670. I don't see anything in that change that would have obviously caused this, since all it did was add a bunch of mostly-turned-off code. But who am I to try to comprehend link.exe's use of memory?

[Eric Seidel (no email)]

(In reply to comment #3)
> If I'm reading this correctly, this seems most likely to place the blame on r55670. I don't see anything in that change that would have obviously caused this, since all it did was add a bunch of mostly-turned-off code. But who am I to try to comprehend link.exe's use of memory?

Unfortunately not.  I should have labeled the columns.

The columns you see are:

status_id, active_bug_id, active_patch_id, author (unused), date, message_text, queue_name

The ids you see are just the attachment ids that the queue tried to process.  It does not record what revision it tried to apply them too, but maybe it should :)

[Adam Roben (:aroben)]

(In reply to comment #4)
> The columns you see are:
> 
> status_id, active_bug_id, active_patch_id, author (unused), date, message_text, queue_name
> 
> The ids you see are just the attachment ids that the queue tried to process.  It does not record what revision it tried to apply them too, but maybe it should :)

Can we assume that EWS bots always update to ToT before applying patches? In that case, the date field should help us figure out what revision they were using.

[Eric Seidel (no email)]

Yes.  EWS bots always update to tip of tree before applying a patch.  I'm not sure why we're missing so many logs in that 12 hour window.  I can look at the on-disk logs as well.  It's possible I stopped the queue for a while.

[Eric Seidel (no email)]

*** Bug 32516 has been marked as a duplicate of this bug. ***

[Adam Roben (:aroben)]

Seems like we aren't having this trouble anymore, probably due to the EWS bots running 64-bit Windows?