pymake builds fail in nsIDOMBatteryManager.h or nsIDOMNavigatorBattery.h since the Paris bindings landed

RESOLVED FIXED in mozilla14

Status

()

Core
DOM
--
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: RyanVM, Assigned: khuey)

Tracking

Trunk
mozilla14
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
This is my first build since the Paris bindings landed. I'm assuming it's related. This is with a completely empty objdir to start.

creating dom/base/test/Makefile
WARNING: Token 'WHITESPACE' defined, but not used
WARNING: c:\mozbuild\mozilla-central\dom\bindings\parser\WebIDL.py:2524: Rule 'OtherOrComma' defined, but not used
WARNING: There is 1 unused token
WARNING: There is 1 unused rule
WARNING: Symbol 'OtherOrComma' is unreachable
WARNING: Symbol 'Other' is unreachable
Generating LALR tables
PrototypeList.h hasn't changed - not touching it
Common.h hasn't changed - not touching it
Common.cpp hasn't changed - not touching it
nsIDOMBatteryManager.idl
nsIDOMNavigatorBattery.idl
main() takes no arguments (1 given)
Traceback (most recent call last):
  File "c:\mozbuild\mozilla-central\build\pymake\pymake\process.py", line 213, in run
    m.__dict__[self.method](self.argv)
TypeError: main() takes no arguments (1 given)
None
c:\mozbuild\mozilla-central\config\rules.mk:1479:0: command 'pythonpath main \
  -Ic:/mozbuild/mozilla-central/other-licenses/ply \
  -Ic:/mozbuild/mozilla-central/xpcom/idl-parser \
  c:/mozbuild/mozilla-central/xpcom/idl-parser/header.py --cachedir=../../xpcom/idl-parser -Ic:/mozbuild/mozilla-central/dom/battery -I../../dist/idl c:/mozbuild/mozilla-central/dom/battery/nsIDOMBatteryManager.idl -d .deps/nsIDOMBatteryManager.h.pp -o _xpidlgen/nsIDOMBatteryManager.h' failed, return code -127
<export>: Found error
<export>: Found error
c:\mozbuild\mozilla-central\config\makefiles\target_export.mk:67:0: command 'c:/mozbuild/python/python.exe c:/mozbuild/mozilla-central/build/pymake/pymake/../make.py -C battery export' failed, return code 2
c:\mozbuild\mozilla-central\config\makefiles\target_export.mk:54:0: command 'c:/mozbuild/python/python.exe c:/mozbuild/mozilla-central/build/pymake/pymake/../make.py -C dom export' failed, return code 2
c:\mozbuild\mozilla-central\config\rules.mk:740:0: command 'c:/mozbuild/python/python.exe c:/mozbuild/mozilla-central/build/pymake/pymake/../make.py export_tier_platform' failed, return code 2
c:\mozbuild\mozilla-central\config\rules.mk:706:0: command 'c:/mozbuild/python/python.exe c:/mozbuild/mozilla-central/build/pymake/pymake/../make.py  tier_platform' failed, return code 2
c:\mozbuild\mozilla-central\client.mk:369:0: command 'c:/mozbuild/python/python.exe c:/mozbuild/mozilla-central/build/pymake/pymake/../make.py -s -j 4 -C c:/mozbuild/mozilla-central/objdir-fx-vc10' failed, return code 2
c:\mozbuild\mozilla-central\client.mk:220:0: command 'c:/mozbuild/python/python.exe c:/mozbuild/mozilla-central/build/pymake/pymake/../make.py -f c:/mozbuild/mozilla-central/client.mk realbuild MOZ_PROFILE_GENERATE=1 MOZ_PGO_INSTRUMENTED=1' failed, return code 2
c:\mozbuild\mozilla-central\client.mk:182:0: command 'c:/mozbuild/python/python.exe c:/mozbuild/mozilla-central/build/pymake/pymake/../make.py -f c:/mozbuild/mozilla-central/client.mk profiledbuild' failed, return code 2
Yeah, bent and I have been seeing this too.  It usually goes away if you make again.
(Reporter)

Comment 2

5 years ago
I filed after it failed twice in a row for me. I thought maybe it just needed a clobber after the first one.
That's odd.  This is not running through our new-binding code, obviously.  Kyle, I didn't think we made changes to the main idl parser, right?  Certainly nothing about it in the diff.

Ryan, if you can reproduce this reliably, would you be willing to try bisecting?
(Reporter)

Comment 4

5 years ago
Confirmed using hg revert. Each test started with an empty objdir.

http://hg.mozilla.org/mozilla-central/rev/031949d40753 - WORKS
http://hg.mozilla.org/mozilla-central/rev/1bdb337e3136 - FAILS

To be clear, I'm building with pymake on Windows 7 x64 SP1. I'm using python 2.7.2, which is what ships with MozillaBuild 1.6. I've reproduced it on two different computers as well (same Windows and MozillaBuild versions, though).

Also, the failure is in nsIDOMNavigatorBattery.h, not nsIDOMBatteryManager.h. Sorry about that.
Summary: pymake builds fail in nsIDOMBatteryManager.h → pymake builds fail in nsIDOMNavigatorBattery.h
(Reporter)

Comment 5

5 years ago
Actually, it appears that it can fail in either. The log in comment 0 shows nsIDOMBatteryManager.h, but the builds are failing in nsIDOMNavigatorBattery.h in my current tests.
Blocks: 740069
Summary: pymake builds fail in nsIDOMNavigatorBattery.h → pymake builds fail in nsIDOMBatteryManager.h or nsIDOMNavigatorBattery.h since the Paris bindings landed
I just got the problem also ... after recent nightly pull my build worked fine, but I needed a clobber and then this came up.

Comment 7

5 years ago
The exact spot where it fails seems to be a bit random. My builds are failing at nsISmsDatabaseService.h. If I start the build again with dirty obj dir, the build works.
Thunderbird developer here.  This just showed up for me too.

A few build attempts and it goes away, which is disturbing.

Comment 9

5 years ago
I get a very similar output on Linux.
(In reply to :aceman from comment #9)
> I get a very similar output on Linux.

Using pymake?

Comment 11

5 years ago
I'm using pymake on windows. 15 or so build attempts and none have got past this error.

Comment 12

5 years ago
khuey, I use the default build: gmake -f client.mk
(In reply to :aceman from comment #12)
> khuey, I use the default build: gmake -f client.mk

Please file a separate bug for whatever you're seeing then.

Comment 14

5 years ago
I don't think that is needed.

I heard you backed out the WebIDL parser update and it builds now for me too.
When using parallel (-jN) option on pymake, this seems to be occur.
(Reporter)

Comment 16

5 years ago
I use -j 4

Comment 17

5 years ago
According to
https://hg.mozilla.org/mozilla-central/rev/ed9cbe6a817e
$(PYTHON_PATH) is extracted to fix this bug.

There are many $(PYTHON_PATH) using in m-c.
Why $PYTHON_PATH only here makes build failure?
(In reply to Takanori MATSUURA from comment #17)
> There are many $(PYTHON_PATH) using in m-c.
> Why $PYTHON_PATH only here makes build failure?

I have no idea, I'm just stabbing in the dark here.

Would like to hear if the failures go away for people after that cset.

Comment 19

5 years ago
Created attachment 612577 [details] [diff] [review]
Fix?

I've formatted pythonpath command lines same as xpcom/idl-parser/Makefile.in.
This means only one variable to be extracted is set per one line.

I'm not sure this is correct because I don't have Windows environment.
Attachment #612577 - Flags: review?(khuey)

Comment 20

5 years ago
Looks good with https://hg.mozilla.org/mozilla-central/rev/ed9cbe6a817e (Win 7 x64, pymake -j4, building comm-central)!

Tried twice with new objdir (which always failed before).
Comment on attachment 612577 [details] [diff] [review]
Fix?

Review of attachment 612577 [details] [diff] [review]:
-----------------------------------------------------------------

No, this is what I don't want to do.  $(PYTHON_PATH) causes pymake to run these commands in a special mode which is what is failing here.
Attachment #612577 - Flags: review?(khuey) → review-
(In reply to H. Hofer from comment #20)
> Looks good with https://hg.mozilla.org/mozilla-central/rev/ed9cbe6a817e (Win
> 7 x64, pymake -j4, building comm-central)!
> 
> Tried twice with new objdir (which always failed before).

Excellent.  Is anyone else still seeing these failures after https://hg.mozilla.org/mozilla-central/rev/ed9cbe6a817e?
(Reporter)

Comment 23

5 years ago
Working fine for me as well.
Assignee: nobody → khuey
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
I can't build on Windows 7, VS2010 with a fresh tree, just pulled, (91225:17e4143dd6f0). The error is more or less what comment 0 says (full output : http://pastebin.mozilla.org/1561032).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I reapplied the hacky fix to the other targets in this directory.

https://hg.mozilla.org/mozilla-central/rev/96a1ab35f765
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
And http://hg.mozilla.org/mozilla-central/rev/7702bca6b64d
You need to log in before you can comment on or make changes to this bug.