#10796 Chromium builds (both x86_64 and aarch64) are hanging in the same place
Closed: Fixed 2 years ago by kevin. Opened 2 years ago by spot.

This one is confusing me. I'm attempting to do builds of Chromium 103 and while they are succeeding for me on my very large AWS EC2 Fedora instance, when I attempt to build them in Koji, both architectures (x86_64 and aarch64) get to the exact same part in the build and then there is no more progress. The build does not fail, there are no errors in the log, it just sits there, presumably forever.

https://koji.fedoraproject.org/koji/taskinfo?taskID=88925465

The last line of output in build.log from both arches is:

[headless_shell:34282/35598] rm -f obj/components/printing/renderer/librenderer.a && "ar" -T -r -c -s -D obj/components/printing/renderer/librenderer.a @"obj/components/printing/renderer/librenderer.a.rsp"

I'm wondering if Chromium has finally gotten so disk or memory hungry that this step is causing build node panics/lockups? Any and all help would be appreciated here.


Sure, happy to try and help figure out whats going on.

It seems to be stuck in a python3 script.

kojibui+ 1129611 99.8 0.0 25360 21760 ? R Jun30 1385:05 /usr/bin/python3 /builddir/build/BUILD/chromium-103.0.5060.53/third_party/catapult/common/py_vulcanize/third_party/rjsmin/rjsmin.py

perhaps this is related to python 3.11 landing?

strace has no output.

it has no file descriptors open but the normal ones:

[root@buildhw-x86-13 ~][PROD-IAD2]# ls -la /proc/1129611/fd
total 0
dr-x------. 2 kojibuilder mock  0 Jul  1 19:15 .
dr-xr-xr-x. 9 kojibuilder mock  0 Jul  1 19:12 ..
lr-x------. 1 kojibuilder mock 64 Jul  1 19:15 0 -> 'pipe:[46116519]'
l-wx------. 1 kojibuilder mock 64 Jul  1 19:15 1 -> 'pipe:[46116520]'
l-wx------. 1 kojibuilder mock 64 Jul  1 19:15 2 -> 'pipe:[46116521]'

Both the aarch64 and x86_64 ones are stuck in the same place/script

kojibui+ 1132755 99.9 0.0 24828 21032 ? R Jun30 1378:04 /usr/bin/python3 /builddir/build/BUILD/chromium-103.0.5060.53/third_party/catapult/common/py_vulcanize/third_party/rjsmin/rjsmin.py

Happy to gather more info if you can let me know what...

Metadata Update from @zlopez:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: medium-gain, medium-trouble, ops

2 years ago

See also Copr issue (Rawhide only, grit.py script hangs in that particular case).

It seems this is fixed? At least I see successful builds and the mass rebuild worked.

What did you end up changing? or was it just some hiesnbug?

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata
Boards 1
ops Status: Backlog