1057832 - TypeError: invalid path component during build

Status: RESOLVED WONTFIX

(Firefox Graveyard :: Web Apps, defect, P3)

Description

[Bill Gianopoulos [:WG9s]]

Official builds getting the following:

*************************
A coding exception was thrown and uncaught in a Task.

Full message: TypeError: invalid path component
Full stack: join@resource://gre/modules/osfile/ospath_win.jsm:148:1
task_DI_initializePublicDownloadList@resource://gre/modules/DownloadIntegration.jsm:202:46
TaskImpl_run@resource://gre/modules/Task.jsm:330:41
TaskImpl@resource://gre/modules/Task.jsm:275:3
createAsyncFunction/asyncFunction@resource://gre/modules/Task.jsm:249:14
Task_spawn@resource://gre/modules/Task.jsm:164:12
this.DownloadIntegration.initializePublicDownloadList@resource://gre/modules/DownloadIntegration.jsm:190:1
this.Downloads.getList/this._promiseListsInitialized<@resource://gre/modules/Downloads.jsm:177:17
TaskImpl_run@resource://gre/modules/Task.jsm:330:41
Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:865:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:744:7

*************************

Comment 1

[Bill Gianopoulos [:WG9s]]

I have 2 questions about this.

1.  Is there some utility to search through logs of official builds to help narrow down when this issue began?

2.  Why does this error not turn the build Red (or at least Orange)?

Comment 2

[Bill Gianopoulos [:WG9s]]

This is failing during the make installer step I am attempting a bisect to find a regressor.

Comment 3

[Bill Gianopoulos [:WG9s]]

Hg bisect found this:

The first bad revision is:
changeset:   200447:9c96b4e6c9ee
user:        Marco Castelluccio <[e-mail]>
date:        Tue Aug 19 08:50:00 2014 -0400
summary:     Bug 911636 - Webapp Runtime migration to Downloads.jsm. r=myk, r=paolo

Comment 4

[Bill Gianopoulos [:WG9s]]

Although the output in comment 0 is from a windows build, this fails similarly in OSX and Linux.

Comment 5

[Bill Gianopoulos [:WG9s]]

This should probably be a webapps bug.

Comment 6

[Bill Gianopoulos [:WG9s]]

[Tracking Requested - why for this release]:

This is either a bogus failure or it needs to be fixed.  Either way it needs to be addressed before release.

Comment 7

[Lawrence Mandel [:lmandel] (use needinfo)]

AFAICT from the comments, this doesn't impact the release but does impact the ability to run a personal build. As such, I'm marking this as tracking-. Do renom if I have misunderstood the impact.

Comment 8

[Bill Gianopoulos [:WG9s]]

[Tracking Requested - why for this release]:

(In reply to Lawrence Mandel [:lmandel] from comment #7)
> AFAICT from the comments, this doesn't impact the release but does impact
> the ability to run a personal build. As such, I'm marking this as tracking-.
> Do renom if I have misunderstood the impact.

The error I pasted was from the full log from an official Mozilla generated Nightly build, so I have no idea why you would say it only effects personal builds.

Comment 9

[Bill Gianopoulos [:WG9s]]

I thought that was clear by me saying "Official builds getting the following"

Comment 10

[Bill Gianopoulos [:WG9s]]

So the official builds, which is what will be the release build are getting what should be a fatal error which is for some reason being ignored, so why would we expect it to work correctly?

Comment 11

[Marco Castelluccio [:marco]]

When do you see the error? During a test?

Comment 12

[Bill Gianopoulos [:WG9s]]

(In reply to Marco Castelluccio [:marco] from comment #11)
> When do you see the error? During a test?

This message is in the build logs.  This has been present in every Official mozilla-central full log file.  Here is an example.  This also occurs during my builds but the messages is in the logs form the official nightly builds.  Here is an example logfile link:

https://tbpl.mozilla.org/php/getParsedLog.php?id=46853343&tree=Mozilla-Central&full=1

Comment 13

[Benjamin Kerensa [:bkerensa]]

Going to track this so we can investigate prior to release

Comment 15

[(not currently active) Ted Mielczarek]

This is happening as part of "make package", specifically where we run xpcshell to generate the startupcache. I don't know why it doesn't fail the build, probably just because we're not actually handling this error. However, if it's not making any tests fail I don't think it's a serious issue, just a hygiene issue.

Comment 16

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Bill Gianopoulos [:WG9s] from comment #9)
> I thought that was clear by me saying "Official builds getting the following"

My mistake. Sorry.

I reviewed this bug with Ted. (See his comment 15.) While we should clean this up, it won't block the release and there is no need to track.

Comment 17

[Bill Gianopoulos [:WG9s]]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #15)
> This is happening as part of "make package", specifically where we run
> xpcshell to generate the startupcache. I don't know why it doesn't fail the
> build, probably just because we're not actually handling this error.
> However, if it's not making any tests fail I don't think it's a serious
> issue, just a hygiene issue.

OK I was actually concerned more about the not failing the build issue because had it done so this would have been caught right away.  That is probably a different bug however.

Comment 18

[Bill Walker [:bwalker] [@wfwalker]]

seems to have no user-facing impact

Comment 19

[Steve Fink [:sfink] [:s:]]

I just ran into this too. I was having some other failure during ./mach package, and this muddied the waters. I spent some time trying to track this down to my patch, when it turned out to be irrelevant.

Note that this message is caused by OS.Constants.Path.profileDir being javascript null. It throws the TypeError when passed into OS.Path.join.

Comment 20

[Landry Breuil (:gaston)]

Fwiw, i'm also seeing this during make package/install on OpenBSD at least for 37 and 38, and maybe even before..

resource://app/modules/WebappManager.jsm
resource://app/modules/WebappRT.jsm
*************************
A coding exception was thrown and uncaught in a Task.

Full message: TypeError: invalid path component
Full stack: join@resource://gre/modules/osfile/ospath_unix.jsm:90:1
task_DI_initializePublicDownloadList@resource://gre/modules/DownloadIntegration.jsm:222:46
TaskImpl_run@resource://gre/modules/Task.jsm:330:41
TaskImpl@resource://gre/modules/Task.jsm:275:3
createAsyncFunction/asyncFunction@resource://gre/modules/Task.jsm:249:14
Task_spawn@resource://gre/modules/Task.jsm:164:12
this.DownloadIntegration.initializePublicDownloadList@resource://gre/modules/DownloadIntegration.jsm:210:1
this.Downloads.getList/this._promiseListsInitialized<@resource://gre/modules/Downloads.jsm:177:17
TaskImpl_run@resource://gre/modules/Task.jsm:330:41
Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:867:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:746:7
this.PromiseWalker.scheduleWalkerLoop/<@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:688
:37

*************************
/usr/obj/ports/firefox-38.0beta1/build-amd64/_virtualenv/bin/python /usr/obj/ports/firefox-38.0beta1/mozilla-beta/toolkit/m
ozapps/installer/find-dupes.py ../../dist/firefox

Comment 21

[Steffen Michalke]

It looks like the problem is triggerd by libffi. I ran into it by using gcc5.1's version (--enable-system-ffi). The libffi shipped with current Nightly is *not* affected (but may have been in the past).

In this case some data wasn't properly imorted to JS (namely profileDir); as a consequence some methods (open, read, access etc.) of the UnixFile object weren't constructed (cf. comment #19). Some other objects seem to be affected as well.

Comment 22

[Myk Melez [:myk] [@mykmelez]]

Per bug 1238079, we're going to disable the desktop web runtime and remove it
from the codebase, so we won't fix these bugs in the integration between Firefox and the runtime.