On Mon, Mar 11, 2024, 04:07 Jerry James <loganjerry@xxxxxxxxx> wrote:
On Sun, Mar 10, 2024 at 10:38 AM Orion Poplawski <orion@xxxxxxxx> wrote:
> I'm starting to see this building perl-Alien-CFITSIO in F40 (not rawhide):
>
> + cd Alien-CFITSIO-v4.4.0.1
> + perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1 NO_PERLLOCAL=1
> Alien::Build::Plugin::PkgConfig::Negotiate> Using PkgConfig plugin:
> PkgConfig::LibPkgConf
> RPM build errors:
>
> I can't reproduce it locally except in mock. Even in mock though if I
> enter the chroot with a shell and run rpmbuid it works, so I'm guessing
> its tty related.
>
> Is anyone else seeing this?
Yes. GDB says:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7a93584 in _IO_new_fclose (fp=0x1) at iofclose.c:48
Downloading source file /usr/src/debug/glibc-2.39-2.fc40.x86_64/libio/iofclose.c
48 if (fp->_flags & _IO_IS_FILEBUF)
(gdb) bt
#0 0x00007ffff7a93584 in _IO_new_fclose (fp=0x1) at iofclose.c:48
#1 0x00007ffff6f690db in XS_PkgConfig__LibPkgConf__Client_DESTROY
(my_perl=<optimized out>, cv=<optimized out>)
at /usr/src/debug/perl-PkgConfig-LibPkgConf-0.11-17.fc40.x86_64/LibPkgConf.xs:311
#2 0x00007ffff7d1288a in Perl_pp_entersub (my_perl=0x5555555592a0)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/pp_hot.c:5555
#3 0x00007ffff7d03718 in Perl_runops_standard (my_perl=0x5555555592a0)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/run.c:41
#4 0x00007ffff7c484da in Perl_call_sv (my_perl=0x5555555592a0,
sv=<optimized out>, flags=<optimized out>)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/perl.c:3150
#5 0x00007ffff7d1b9cf in S_curse
(my_perl=my_perl@entry=0x5555555592a0, sv=sv@entry=0x555557dba810,
check_refcnt=check_refcnt@entry=true) at
/usr/src/debug/perl-5.38.2-506.fc40.x86_64/sv.c:7144
#6 0x00007ffff7d1c1c0 in Perl_sv_clear
(my_perl=my_perl@entry=0x5555555592a0,
orig_sv=orig_sv@entry=0x555557dba810)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/sv.c:6685
#7 0x00007ffff7d16482 in Perl_sv_free2 (my_perl=0x5555555592a0,
sv=0x555557dba810, rc=<optimized out>)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/sv.c:7244
#8 0x00007ffff7d4d025 in Perl_leave_scope
(my_perl=my_perl@entry=0x5555555592a0, base=<optimized out>)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/scope.c:1429
#9 0x00007ffff7d52658 in Perl_dounwind (cxix=<optimized out>,
my_perl=<optimized out>)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/pp_ctl.c:1669
#10 Perl_dounwind (my_perl=my_perl@entry=0x5555555592a0, cxix=10)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/pp_ctl.c:1658
#11 0x00007ffff7d52b19 in Perl_die_unwind (my_perl=0x5555555592a0,
msv=<optimized out>)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/pp_ctl.c:1901
#12 0x00007ffff7ce0b8b in Perl_croak_sv (my_perl=0x5555555592a0,
baseex=<optimized out>)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/util.c:1861
#13 0x00007ffff7ce0b9d in Perl_die_sv (my_perl=<optimized out>,
baseex=<optimized out>)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/util.c:1780
#14 0x00007ffff7d61061 in Perl_pp_die (my_perl=0x5555555592a0)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/pp_sys.c:509
#15 0x00007ffff7d03718 in Perl_runops_standard (my_perl=0x5555555592a0)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/run.c:41
#16 0x00007ffff7c47899 in S_run_body (oldscope=<optimized out>,
my_perl=<optimized out>)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/perl.c:2807
#17 perl_run (my_perl=0x5555555592a0) at
/usr/src/debug/perl-5.38.2-506.fc40.x86_64/perl.c:2727
#18 0x0000555555555342 in main (argc=<optimized out>, argv=<optimized
out>, env=<optimized out>)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/perlmain.c:127
Frame 1 is this code:
void
DESTROY(self)
my_client_t *self;
CODE:
if(self->auditf != NULL)
{
fclose(self->auditf);
self->auditf = NULL;
}
pkgconf_client_deinit(&self->client);
SvREFCNT_dec(self->error_handler);
Safefree(self);
and indeed, self->auditf != NULL, because it is equal to 1, so it is
passed to fclose, triggering the segfault. Setting a hardware
watchpoint to catch the transition to the value 1 turns up this:
Old value = (FILE *) 0x0
New value = (FILE *) 0x1
pkgconf_cache_add (client=0x555557f4cd70, pkg=0x555557f4d320) at
libpkgconf/cache.c:136
Downloading source file
/usr/src/debug/pkgconf-2.1.0-1.fc40.x86_64/libpkgconf/cache.c
136 client->cache_table =
pkgconf_reallocarray(client->cache_table,
(gdb) bt
#0 pkgconf_cache_add (client=0x555557f4cd70, pkg=0x555557f4d320) at
libpkgconf/cache.c:136
#1 pkgconf_cache_add (client=client@entry=0x555557f4cd70,
pkg=pkg@entry=0x555557f4d320) at libpkgconf/cache.c:123
#2 0x00007ffff6f5c6af in pkgconf_pkg_find (client=0x555557f4cd70,
name=name@entry=0x555555c01240 "cfitsio")
at libpkgconf/pkg.c:825
#3 0x00007ffff6f692fc in XS_PkgConfig__LibPkgConf__Client__find
(my_perl=<optimized out>, cv=<optimized out>)
at /usr/src/debug/perl-PkgConfig-LibPkgConf-0.11-17.fc40.x86_64/LibPkgConf.xs:324
#4 0x00007ffff7d1288a in Perl_pp_entersub (my_perl=0x5555555592a0)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/pp_hot.c:5555
#5 0x00007ffff7d03718 in Perl_runops_standard (my_perl=0x5555555592a0)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/run.c:41
#6 0x00007ffff7c47899 in S_run_body (oldscope=<optimized out>,
my_perl=<optimized out>)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/perl.c:2807
#7 perl_run (my_perl=0x5555555592a0) at
/usr/src/debug/perl-5.38.2-506.fc40.x86_64/perl.c:2727
#8 0x0000555555555342 in main (argc=<optimized out>, argv=<optimized
out>, env=<optimized out>)
at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/perlmain.c:127
This declaration is at the top of LibPkgConf.xs:
struct my_client_t {
pkgconf_client_t client;
FILE *auditf;
int maxdepth;
SV *error_handler;
};
So an operation on the client field is being done, but the following
field is affected. Starting over with a breakpoint on
pkgconf_cache_add shows that this is happening on the very first call
to that function. It happens when client->cache_count is incremented
on line 135, just before the realloc:
++client->cache_count;
client->cache_table = pkgconf_reallocarray(client->cache_table,
client->cache_count, sizeof (void *));
which can only mean that different compilation units have seen
different definitions of the pkgconf_client_t type. And here we
notice that the latest build of pkgconf is version 2.1.0 from 12
February 2024, and the latest build of perl-PkgConfig-LibPkgConf is
perl-PkgConfig-LibPkgConf-0.11-18.fc40 from 29 February 2024 ... but
it hasn't gone stable yet. The version you are getting in F40 mock is
perl-PkgConfig-LibPkgConf-0.11-17.fc40 from 25 January 2024, built
against pkgconf 1.9.5, which had a different definition of
pkgconf_client_t.
Your choices are to wait for the F40 beta freeze to end, or lobby for
a freeze exception for the perl-PkgConfig-LibPkgConf update.
Does this mean that pkgconf had an undetected ABI change? And that possibly more things would need to be rebuilt and / or pkgconf be fixed / bump its soname?
Fabio
Regards,
--
Jerry James
http://www.jamezone.org/
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
