Closed Bug 1471681 Opened 4 years ago Closed 4 years ago

dxr's mozilla-central and mozilla-beta trees have stopped updating

Categories

(Webtools Graveyard :: DXR, defect)

Product:
Webtools Graveyard
Component:
DXR
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: aryx, Unassigned)

References

Details

mozilla-central and mozilla-beta have stopped updating.

From the log:
17:59:43 33:46.79    Compiling geckoservo v0.0.1 (file:///home/jenkins/src/mozilla-central/servo/ports/geckolib)
17:59:43 33:47.04 storage
18:00:25 34:28.95 storage/build
18:00:31 34:35.34 storage/test/gtest
18:00:40 34:44.01 extensions/cookie
18:00:58 35:02.69 error[E0432]: unresolved import `std::alloc::set_alloc_error_hook`
18:00:58 35:02.69    --> toolkit/library/rust/shared/lib.rs:225:30
18:00:58 35:02.69     |
18:00:58 35:02.69 225 |     use std::alloc::{Layout, set_alloc_error_hook};
18:00:58 35:02.69     |                              ^^^^^^^^^^^^^^^^^^^^ no `set_alloc_error_hook` in `alloc`
18:00:59 35:03.02 error: aborting due to previous error

This is from bug 1469766
m-c updated over the weekend, but beta is still behind.
This is our official code search tool and so we really need monitoring for this so it doesn't keep breaking.
Duplicate of this bug: 1479397
It looks like we need to update to the 2018-06-20 nightly of Rust to get the new set_alloc_error_hook. I'll see what I can do.
(In reply to Erik Rose [:erik][:erikrose] from comment #5)
> It looks like we need to update to the 2018-06-20 nightly of Rust to get the
> new set_alloc_error_hook. I'll see what I can do.

weird; I rebuilt the docker images last week and they should have already picked that up.  Just re-ran and:

> nightly installed - rustc 1.29.0-nightly (866a71325 2018-07-29)
Ah, my checkout is old, and we weren't asking rustup for nightlies then. In that case, I'm not sure what's going on. https://jenkins-dxr.mozilla.org/job/mozilla-central/ indicates it's been working on a single moz-central build since July 5. I cancelled that, because that's ridiculous. I've started a new build: https://jenkins-dxr.mozilla.org/job/mozilla-central/1389/. Let's see what happens. Any build that goes on for a week should probably self-destruct and call for help anyway. Yikes.
Okay, now we have a different error, very early in the build. Something during configuration is getting a value that surprises it:

 0:10.16 checking cargo version... 1.29.0
 0:10.23 Traceback (most recent call last):
 0:10.23   File "/home/jenkins/src/mozilla-central/configure.py", line 123, in <module>
 0:10.23     sys.exit(main(sys.argv))
 0:10.24   File "/home/jenkins/src/mozilla-central/configure.py", line 29, in main
 0:10.24     sandbox.run(os.path.join(os.path.dirname(__file__), 'moz.configure'))
 0:10.24   File "/home/jenkins/src/mozilla-central/python/mozbuild/mozbuild/configure/__init__.py", line 428, in run
 0:10.24     func(*args)
 0:10.24   File "/home/jenkins/src/mozilla-central/python/mozbuild/mozbuild/configure/__init__.py", line 474, in _value_for
 0:10.24     return self._value_for_depends(obj, need_help_dependency)
 0:10.24   File "/home/jenkins/src/mozilla-central/python/mozbuild/mozbuild/util.py", line 944, in method_call
 0:10.24     cache[args] = self.func(instance, *args)
 0:10.24   File "/home/jenkins/src/mozilla-central/python/mozbuild/mozbuild/configure/__init__.py", line 483, in _value_for_depends
 0:10.24     return obj.result(need_help_dependency)
 0:10.24   File "/home/jenkins/src/mozilla-central/python/mozbuild/mozbuild/util.py", line 944, in method_call
 0:10.24     cache[args] = self.func(instance, *args)
 0:10.24   File "/home/jenkins/src/mozilla-central/python/mozbuild/mozbuild/configure/__init__.py", line 123, in result
 0:10.24     return self._func(*resolved_args)
 0:10.24   File "/home/jenkins/src/mozilla-central/python/mozbuild/mozbuild/configure/__init__.py", line 1003, in wrapped
 0:10.24     return new_func(*args, **kwargs)
 0:10.24   File "/home/jenkins/src/mozilla-central/build/moz.configure/rust.configure", line 122, in rust_supported_targets
 0:10.24     t = split_triplet(t, allow_unknown=True)
 0:10.24   File "/home/jenkins/src/mozilla-central/python/mozbuild/mozbuild/configure/__init__.py", line 1003, in wrapped
 0:10.24     return new_func(*args, **kwargs)
 0:10.24   File "/home/jenkins/src/mozilla-central/build/moz.configure/init.configure", line 595, in split_triplet
 0:10.24     cpu, manufacturer, os = triplet.split('-', 2)
 0:10.24 ValueError: need more than 2 values to unpack
That looks like bug 1479540.
Yes indeed. It looks like the fix has been r+'d, so we should be good once it lands.
Depends on: 1479540
m-c: This page was generated by DXR 2018-8-02 2:22. 
m-b: This page was generated by DXR 2018-6-19 5:28. 

m-b keeps stalling. Do we have to uplift bug 1479540?
The central run is stuck again: "This page was generated by DXR 2018-8-04 12:14."
This seems to be broken again, can someone take a look at it?
Flags: needinfo?(erik)
My guess (without looking at anything) is that this is due to the new Node requirement for building Firefox. (The SearchFox equivalent is bug 1484018).
DXR is broken since 2018-8-04. Node requirement would not be sufficient although it is also required.
See Also: → 1484554
as noted, node was behind; cbindgen was also missing and I've added that. build is currently running. next question is if we're going to run into memory limits *again*.
Flags: needinfo?(erik)
m-c start working again:
> This page was generated by DXR 2018-8-23 0:39.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.