Bug 1818011 - gdb fails to build with Python 3.9: overflow in conversion from 'unsigned int' to 'int'
Summary: gdb fails to build with Python 3.9: overflow in conversion from 'unsigned int...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gdb
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Sergio Durigan Junior
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1822468
Blocks: PYTHON39
TreeView+ depends on / blocked
 
Reported: 2020-03-27 12:29 UTC by Miro Hrončok
Modified: 2020-05-09 03:12 UTC (History)
8 users (show)

Fixed In Version: gdb-9.1-5.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-09 15:56:42 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Miro Hrončok 2020-03-27 12:29:04 UTC
gdb fails to build with Python 3.9.0a5.

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../bfd -DBINDIR=\"/usr/bin\" -DLIBDIR=\"/usr/lib64\" -I. -I../../bfd -I../../bfd/../include -DHAVE_x86_64_elf64_vec -DHAVE_i386_elf32_vec -DHAVE_iamcu_elf32_vec -DHAVE_x86_64_elf32_vec -DHAVE_i386_pei_vec -DHAVE_x86_64_pei_vec -DHAVE_l1om_elf64_vec -DHAVE_k1om_elf64_vec -DHAVE_elf64_le_vec -DHAVE_elf64_be_vec -DHAVE_elf32_le_vec -DHAVE_elf32_be_vec -DHAVE_s390_elf32_vec -DHAVE_s390_elf64_vec -DHAVE_powerpc_elf32_vec -DHAVE_rs6000_xcoff_vec -DHAVE_powerpc_elf32_le_vec -DHAVE_powerpc_boot_vec -DHAVE_powerpc_elf64_vec -DHAVE_powerpc_elf64_le_vec -DHAVE_arm_elf32_le_vec -DHAVE_arm_elf32_fdpic_le_vec -DHAVE_arm_elf32_be_vec -DHAVE_arm_elf32_fdpic_be_vec -DHAVE_aarch64_elf64_le_vec -DHAVE_aarch64_elf64_be_vec -DHAVE_aarch64_elf32_le_vec -DHAVE_aarch64_elf32_be_vec -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -MT elf.lo -MD -MP -MF .deps/elf.Tpo -c ../../bfd/elf.c -o elf.o
../../bfd/elf.c: In function 'setup_group':
../../bfd/elf.c:752:35: error: overflow in conversion from 'unsigned int' to 'int' changes value from 'num_group = 4294967295' to '-1' [-Werror=overflow]
  752 |     elf_tdata (abfd)->num_group = num_group = -1;
      |                                   ^~~~~~~~~
mv -f .deps/elf64.Tpo .deps/elf64.Plo

For the build logs, see:
https://copr-be.cloud.fedoraproject.org/results/@python/python3.9/fedora-rawhide-x86_64/01321687-gdb/

For all our attempts to build gdb with Python 3.9, see:
https://copr.fedorainfracloud.org/coprs/g/python/python3.9/package/gdb/

Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.9:
https://copr.fedorainfracloud.org/coprs/g/python/python3.9/

Let us know here if you have any questions.

Python 3.9 will be included in Fedora 33. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.9.
A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon.
We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.

Comment 1 Miro Hrončok 2020-04-05 23:21:04 UTC
Setting the severity to high.

This package is part of the initial bootstrap sequence. Without it, we cannot proceed with the Python 3.9 bootstrap in a Koji side tag.

https://fedoraproject.org/wiki/Changes/Python3.9#Important_dates_and_plan

The current plan is to follow the "ideal point when we can start rebuilding in Koji" -- that is we need to get this bug fixed approximately in 1 month and 1 week.

That includes potential uncovered bugs in packages that depend on this one.

Please acknowledge that you have read this message and that you can dedicate time to fix it. If you know already that you won't be able to fix it by the deadline, please let us know ASAP, so we can allocate resources to do that. Thank You.

Comment 2 Sergio Durigan Junior 2020-04-06 21:17:05 UTC
Sorry for the delay, I am aware of the issue and will try to fix it ASAP.

Comment 3 Miro Hrončok 2020-04-06 21:28:39 UTC
Thanks!

Comment 4 Sergio Durigan Junior 2020-04-08 01:33:39 UTC
Just an update on this.

Kevin is looking into fixing it, but the bug seems to be related to binutils, and not GDB.  We might have to reassign it.

Also, I'd be interested in knowing why this error (which seems to be completely unrelated to the Python support on GDB) happens on the copr repository, but not on Rawhide.  I'm assuming the GCC being used is newer than the one available on Rawhide.

Comment 5 Miro Hrončok 2020-04-08 07:35:45 UTC
> Also, I'd be interested in knowing why this error (which seems to be completely unrelated to the Python support on GDB) happens on the copr repository, but not on Rawhide.

That is a mystery to me as well. There are root logs in case you want to compare them with rawhide root logs.

For the gdb build, this is from our repo:

libbabeltrace-devel       x86_64  1.5.8-1.fc33
libselinux-devel          x86_64  3.0-4.fc33
python3-devel             x86_64  3.9.0~a5-1.fc33
rpm-devel                 x86_64  4.15.90-0.git14971.3.fc33
boost                     x86_64  1.69.0-16.fc33
boost-atomic              x86_64  1.69.0-16.fc33
boost-chrono              x86_64  1.69.0-16.fc33
boost-container           x86_64  1.69.0-16.fc33
boost-context             x86_64  1.69.0-16.fc33
boost-contract            x86_64  1.69.0-16.fc33
boost-coroutine           x86_64  1.69.0-16.fc33
boost-date-time           x86_64  1.69.0-16.fc33
boost-devel               x86_64  1.69.0-16.fc33
boost-fiber               x86_64  1.69.0-16.fc33
boost-filesystem          x86_64  1.69.0-16.fc33
boost-graph               x86_64  1.69.0-16.fc33
boost-iostreams           x86_64  1.69.0-16.fc33
boost-locale              x86_64  1.69.0-16.fc33
boost-log                 x86_64  1.69.0-16.fc33
boost-math                x86_64  1.69.0-16.fc33
boost-program-options     x86_64  1.69.0-16.fc33
boost-random              x86_64  1.69.0-16.fc33
boost-regex               x86_64  1.69.0-16.fc33
boost-serialization       x86_64  1.69.0-16.fc33
boost-stacktrace          x86_64  1.69.0-16.fc33
boost-system              x86_64  1.69.0-16.fc33
boost-test                x86_64  1.69.0-16.fc33
boost-thread              x86_64  1.69.0-16.fc33
boost-timer               x86_64  1.69.0-16.fc33
boost-type_erasure        x86_64  1.69.0-16.fc33
boost-wave                x86_64  1.69.0-16.fc33
libbabeltrace             x86_64  1.5.8-1.fc33
libblkid-devel            x86_64  2.35.1-7.fc33
libmount-devel            x86_64  2.35.1-7.fc33
libuuid-devel             x86_64  2.35.1-7.fc33
python-pip-wheel          noarch  20.0.2-2.fc33
python-setuptools-wheel   noarch  46.1.3-1.fc33
python3                   x86_64  3.9.0~a5-1.fc33
python3-libs              x86_64  3.9.0~a5-1.fc33
python3-rpm-generators    noarch  11-1.fc33
python3-setuptools        noarch  46.1.3-1.fc33
rpm-sign-libs             x86_64  4.15.90-0.git14971.3.fc33


Everything else is from rawhide (Koji repo).


> I'm assuming the GCC being used is newer than the one available on Rawhide.

We don't build newer gcc in that repo.

Comment 6 Sergio Durigan Junior 2020-04-08 18:03:01 UTC
FWIW, I was able to reproduce the problem on Rawhide (outside mock).

Even though this is a binutils problem, we should be able to fix this on GDB as well (since GDB carries its own copy of bfd).

Comment 7 Sergio Durigan Junior 2020-04-08 18:31:53 UTC
The following commit fixed the issue upstream:

commit cda7e5603f6efd7c3716e45cc6ea11b70dd8daae 
Author: H.J. Lu <hjl.tools>
Date:   Tue Mar 24 04:52:39 2020 -0700
                                               
    bfd: Change num_group to unsigned int

Comment 8 Sergio Durigan Junior 2020-04-09 02:18:15 UTC
The i686/armv7hl buildroots seem to have some problem:

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

We don't know why this segfault is happening, since we haven't changed anything else other than backport the patch (which is extremely simple).  We'll try to find out what's going on.

Comment 9 Kevin Buettner 2020-04-09 15:56:42 UTC
I think this should now be fixed in gdb-9.1-5.

Comment 10 Miro Hrončok 2020-04-09 16:59:04 UTC
Indeed it is. There is another failure with Python 3.9. I've opened a new bugzilla, bz1822715.

Comment 11 Fedora Update System 2020-05-06 20:24:42 UTC
FEDORA-2020-0bc8abfe7d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0bc8abfe7d

Comment 12 Fedora Update System 2020-05-07 05:21:13 UTC
FEDORA-2020-0bc8abfe7d has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-0bc8abfe7d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0bc8abfe7d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 13 Fedora Update System 2020-05-09 03:12:42 UTC
FEDORA-2020-0bc8abfe7d has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.