So, over at upstream they raised the suspicion that some parts of what
I'm linking are compiled with different flags. To recap: I get
```
/usr/include/c++/15/bits/stl_vector.h:1262: std::vector<_Tp,
_Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type)
[with _Tp = const char*; _Alloc = std::allocator<const char*>;
reference = const char*&; size_type = long unsigned int]: Assertion
'__n < this->size()' failed.
Aborted (core dumped)
```
in a part of code which basically does:
```
FZ_FUNCTION std::vector<std::string>
pdf_choice_widget_options2(fz_context* ctx, pdf_annot* tw, int
exportval)
{
int n = pdf_choice_widget_options(ctx, tw, exportval, nullptr);
std::vector<const char*> opts(n);
int n2 = pdf_choice_widget_options(ctx, tw, exportval, &opts[0]);
assert(n2 == n);
std::vector<std::string> ret(n);
for (int i=0; i<n; ++i)
{
ret[i] = opts[i];
}
return ret;
}
```
Is there anything regarding flags like NDEBUG, GLIBCXX_ASSERTIONS and
the like which could make the above throw when the .so is compiled
with different flags compared to the code that calls it? Something
that appeared with gcc15 or libstdc++ in gcc15?
Michael
Am Sa., 25. Jan. 2025 um 16:55 Uhr schrieb Michael J Gruber
<mjg@xxxxxxxxxxxxxxxxx>:
>
> Trying to get to the bottom of things. I can reproduce it now in mock
> locally, it occurs in `page.first_widget` in the first subtest in
> test_widgets.py (or any other subtest), and this throws
>
> ```
> /usr/include/c++/15/bits/stl_vector.h:1262: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = const char*; _Alloc = std::allocator<const char*>; reference = const char*&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
> Aborted (core dumped)
> ```
>
> Regarding that bit of C++ I have aura-- ...
>
> I reproduced that test snipped and added *two* widgets instead of one.
> Accessing page.first_widget still gives the same error, so it's no
> off-by-one error or such.
>
> But maybe STL rings a bell?
>
> Michael
>
>
> Iñaki Ucar venit, vidit, dixit 2025-01-25 15:25:59:
> > Do you have more details about why the test crashes? I have a similar case
> > [1] (i.e. mass rebuild fine, then FTBFS), and the only relevant dependency
> > change was glibc. It's also in the report Koschei gives for your package,
> > so I'm inclined to think it's a similar thing.
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2341839
> >
> > Iñaki
> >
> > On Sat, 25 Jan 2025 at 13:53, Michael J Gruber <mjg@xxxxxxxxxxxxxxxxx>
> > wrote:
> >
> > > Hi there,
> > >
> > > I have a FTBFS that I can't wrap my head around. Maybe some of you
> > > have experienced similar weirdness after the mass rebuild.
> > >
> > > python-PyMuPDF-1.25.1-2.fc42 FTBFS in rawhide according to koschei [1]
> > > and koji scratch [2]. Indeed, the build itself succeeds but a test
> > > fails because a thread gets aborted.
> > >
> > > The same version built and tested fine during the mass rebuild [3],
> > > and python-PyMuPDF-1.25.1-1.fc42 before [1], with the only difference
> > > being the empty mass rebuild bump commit.
> > >
> > > The main dependency is mupdf-devel-1.25.2-2.fc42 and friends, and
> > > again the only before/after change here is the mass release bump; this
> > > one does not have a test suite, though, and basically the PyMuPDF
> > > tests test mupdf.
> > >
> > > As you can see in my copr integration testing [4] [5], the same
> > > versions worked on all things Fedora/EPEL a month ago.
> > > Today I triggered a rebuild of the mass rebuild versions there, and
> > > now those same versions build and test fine everywhere except all
> > > rawhide chroots.
> > >
> > > I *think* that the same version worked in mockbuild until a few days
> > > ago, but I may be mistaken. It fails now.
> > >
> > > So what's the difference? Something related to gcc15/swig/llvm, i.e.
> > > changed/misbuilt python bindings? A new pytest timeout killing a test?
> > >
> > > Totally stomped, looking for pointers (huh).
> > >
> > > Cheers
> > > Michael
> > >
> > > [1]
> > > https://koschei.fedoraproject.org/package/python-PyMuPDF?collection=f42
> > > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=128458691
> > > [3] https://koji.fedoraproject.org/koji/buildinfo?buildID=2631525
> > > [4] https://copr.fedorainfracloud.org/coprs/mjg/mupdf/builds/
> > > [5] https://copr.fedorainfracloud.org/coprs/mjg/python-PyMuPDF/builds/
> > > --
> > > _______________________________________________
> > > 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
> > >
> >
> >
> > --
> > Iñaki Úcar
--
_______________________________________________
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
