Closed
Bug 1057832
Opened 10 years ago
Closed 9 years ago
TypeError: invalid path component during build
Categories
(Firefox Graveyard :: Web Apps, defect, P3)
Firefox Graveyard
Web Apps
Tracking
(firefox34-)
RESOLVED
WONTFIX
Tracking | Status | |
---|---|---|
firefox34 | - | --- |
People
(Reporter: wgianopoulos, Unassigned)
References
Details
(Keywords: regression)
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
*************************
Reporter | ||
Comment 1•10 years ago
|
||
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)?
Severity: normal → major
Reporter | ||
Comment 2•10 years ago
|
||
This is failing during the make installer step I am attempting a bisect to find a regressor.
Reporter | ||
Updated•10 years ago
|
Keywords: regression
Reporter | ||
Comment 3•10 years ago
|
||
Hg bisect found this:
The first bad revision is:
changeset: 200447:9c96b4e6c9ee
user: Marco Castelluccio <mar.castelluccio@studenti.unina.it>
date: Tue Aug 19 08:50:00 2014 -0400
summary: Bug 911636 - Webapp Runtime migration to Downloads.jsm. r=myk, r=paolo
Blocks: 911636
Reporter | ||
Comment 4•10 years ago
|
||
Although the output in comment 0 is from a windows build, this fails similarly in OSX and Linux.
Reporter | ||
Comment 5•10 years ago
|
||
This should probably be a webapps bug.
Component: Download Manager → Web Apps
Product: Toolkit → Firefox
Reporter | ||
Comment 6•10 years ago
|
||
[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.
tracking-firefox34:
--- → ?
Comment 7•10 years ago
|
||
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.
Reporter | ||
Comment 8•10 years ago
|
||
[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.
Reporter | ||
Comment 9•10 years ago
|
||
I thought that was clear by me saying "Official builds getting the following"
Reporter | ||
Comment 10•10 years ago
|
||
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•10 years ago
|
||
When do you see the error? During a test?
Reporter | ||
Comment 12•10 years ago
|
||
(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 15•10 years ago
|
||
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•10 years ago
|
||
(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.
Reporter | ||
Comment 17•10 years ago
|
||
(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•10 years ago
|
||
seems to have no user-facing impact
Severity: major → normal
Priority: -- → P3
Comment 19•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
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•9 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•9 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•