Builds hang after "Finished release [optimized] target(s) in X.XXs"
Categories
(Firefox Build System :: General, defect, P3)
Tracking
(Not tracked)
People
(Reporter: mac198442, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0
Steps to reproduce:
My local builds with both mozilla-central and mozilla-beta often hang after rust 1.35.
Actual results:
The builds hang with the last log message being "Finished release [optimized] target(s) in X.XXs"
Expected results:
The build should have completed normaly.
So far this has only happened with builds under Linux and I have not seen this under Windows. This seems to be related to the number of parallel makes you permit. With the default of mk_add_options MOZ_MAKE_FLAGS="-j4" i have not reproduced this. With my normal .mozconfig with "mk_add_options MOZ_MAKE_FLAGS="-j3", this happens often changing it to -j2 results in it almost always failing and i have the idea that changing it to -j1 will always fail.
So my sense is this started when I updated rust, but then that could have just impacted the timing. I fell this is either a mach or a rust issue but I have not determined which and don;t feel I have the expertise to figure it out I am now just building with -j4 (which makes my webserver less responsive during build times.
Here is a log file form a hang using mk_add_options MOZ_MAKE_FLAGS="-j2" in .mozconfig. seems I was wrong specifying .j1 must be a special case and seems to never hang.
log.txt
Oh BTW preventing using -j2 and -j3 is NOT an acceptable solution.
Seems I was premature saying running with the default -j4 avoids the issue it does not. It is also possible this has nothing to do with the number of parallel makes.
With a -v on the mach call it seems the build crashes rather than hanging. The complete log file of the build is attached.
|
||
Updated•5 years ago
|
This issue seems to no longer exist.
Tnis bug has reappeared. I suspect it is fixed by bug 1646936.
|
||
Comment 9•2 years ago
|
||
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.
|
||
Comment 10•1 year ago
|
||
:mac198442 do you still encounter this problem? If not, we'll go ahead and close this.
|
|
||
Updated•1 year ago
|
|
Reporter | |
Comment 11•1 year ago
|
||
This still happens and only mozilla-central and not on earlier versions. Also only happens only on my build system which is running fedora27 to provide more backwards compatibility. I suspect it might be a fedora27 issue and not a mozilla issue.
|
|
Reporter | |
Comment 12•8 months ago
|
||
Silly me realized that perhaps the reason it only happens on mozilla-central could be because for central I do the linux-64 and macOS cross-compiles in parallel and for the earlier versions I do them sequentially. since changing to not trying to do parallel builds this has not occurred. I am closing this as INVALID at least for now.
|
|
Reporter | |
Comment 13•8 months ago
|
||
(In reply to mac198442 from comment #12)
Silly me realized that perhaps the reason it only happens on mozilla-central could be because for central I do the linux-64 and macOS cross-compiles in parallel and for the earlier versions I do them sequentially. since changing to not trying to do parallel builds this has not occurred. I am closing this as INVALID at least for now.
That said, however, I think the issue is that you cannot do parallel is that the lock files that are in the source directory really should be in the object directory.
|
||
Comment 14•8 months ago
|
||
The lock files are not even in the source directory. They are in $HOME/.cargo.
|
|
Reporter | |
Comment 15•8 months ago
|
||
ah but it seems one set of lock files for multiple builds does not seem to work
Description
•