IOT instruction (core dumped). Assertion '__n < this->size()' failed.

[duguyipiao]

With the latest development version, I cannot open the attached file, which can be opened normally with mupdf. I get the following core dumped error under linux.

/usr/include/c++/14.2.1/bits/stl_vector.h:1130: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = int; _Alloc = std::allocator<int>; reference = int&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
[1]    41151 IOT instruction (core dumped)  sioyek Supplemental__Material.pdf

Supplemental__Material.pdf

[ahrm]

Can't reproduce the issue on linux. Some more information might help, e.g. what is your exact build process? (e.g. do you use the system's mupdf or the mupdf included in this repo?)

[duguyipiao]

I installed the sioyek-git package from aur, which I think uses the system mupdf.

P.S. I'm using Manjaro Linux, which has libmupdf 1.24.8-1.

[vp1981]

Hello. I'm experiencing the same issue here with a different PDF file. Here is the output of the gdb bt:

[Thread 0x7fffa30006c0 (LWP 270944) exited]
/usr/include/c++/14.2.1/bits/stl_vector.h:1130: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = int; _Alloc = std::allocator<int>; reference = int&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.

Thread 1 "sioyek" received signal SIGABRT, Aborted.
Downloading source file /usr/src/debug/glibc/glibc/nptl/pthread_kill.c
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
44        return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
(gdb) bt
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007ffff22a5463 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:78
#2  0x00007ffff224c120 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007ffff22334c3 in __GI_abort () at abort.c:79
#4  0x00007ffff24d3bb0 in std::__glibcxx_assert_fail (file=file@entry=0x55555588f6f8 "/usr/include/c++/14.2.1/bits/stl_vector.h", line=line@entry=1130,
    function=function@entry=0x555555891d48 "std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = int; _Alloc = std::allocator<int>; reference = int&; size_type = long unsigned int]",
    condition=condition@entry=0x555555888859 "__n < this->size()") at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/assert_fail.cc:41
#5  0x00005555556014d0 in std::vector<int, std::allocator<int> >::operator[] (this=<optimized out>, __n=<optimized out>) at /usr/include/c++/14.2.1/bits/stl_vector.h:1128
#6  std::vector<int, std::allocator<int> >::operator[] (this=<optimized out>, __n=<optimized out>) at /usr/include/c++/14.2.1/bits/stl_vector.h:1128
#7  Document::count_chapter_pages_accum (this=<optimized out>, accum_page_counts=...) at pdf_viewer/document.cpp:660
#8  Document::convert_toc_tree (this=this@entry=0x5555572eebd0, root=<optimized out>, root@entry=0x55555733d0b0, output=std::vector of length 8, capacity 8 = {...}) at pdf_viewer/document.cpp:814
#9  0x000055555560203d in Document::create_toc_tree (this=0x5555572eebd0, toc=std::vector of length 8, capacity 8 = {...}) at pdf_viewer/document.cpp:798
#10 0x000055555561511e in Document::load_document_caches (this=0x5555572eebd0, invalid_flag=0x5555560b5150, force_now=<optimized out>) at pdf_viewer/document.cpp:2934
#11 0x000055555560da65 in Document::open (this=0x5555572eebd0, invalid_flag=0x5555560b5150, force_load_dimensions=false, password="", temp=false) at pdf_viewer/document.cpp:1014
#12 0x000055555584da43 in DocumentView::open_document(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, bool*, bool, std::optional<OpenedBookState>, bool) [clone .constprop.0] [clone .isra.0] (
    this=this@entry=0x555555f44490, invalid_flag=invalid_flag@entry=0x5555560b5150, load_prev_state=load_prev_state@entry=true, force_load_dimensions=force_load_dimensions@entry=false, prev_state=..., doc_path=...) at pdf_viewer/document_view.cpp:752
#13 0x00005555556d1586 in MainWidget::open_document (this=0x5555560b4b50, path=..., offset_x=std::optional [no contained value], offset_y=std::optional [no contained value], zoom_level=std::optional [no contained value]) at pdf_viewer/main_widget.cpp:1920
#14 0x00005555556cc806 in handle_args (arguments=..., origin=<optimized out>, origin@entry=0x0) at pdf_viewer/main.cpp:620
#15 0x00005555555d05f1 in main (argc=<optimized out>, args=<optimized out>) at pdf_viewer/main.cpp:874

I hope this helps.

P.S. I'm on Archlinux with self-compiled sioyek from git (https://git.sr.ht/~vp1981/pkgbuild/tree/master/item/sioyek/PKGBUILD).

[ahrm]

This is very weird. The crash seems to be caused in this line: https://github.com/ahrm/sioyek/blob/40151569b95cac47d708447b181e645178082aa0/pdf_viewer/document.cpp#L660. But it is literally impossible for the index to be out of range because we check for that in the for loop. Can you set a breakpoint on Document::count_chapter_pages_accum and see exactly what happens in that function?

[vp1981]

It's something really weird.

I built sioyek locally from git (with and without CONFIG=+debug) and it worked fine! Then I rebuilt the Archlinux package, but it still crashes at the same point.

The package build host is almost the same as the one I tested the sioyek local build on, but it is only accessible via ssh.

Another oddity is that the sioyek from the package is smaller than the local build, even after running strip:

LANG=en_US.UTF-8 stat -c '%s -- %n' ./sioyek ; stat -c '%s -- %n' /usr/bin/sioyek ; stat -c '%s -- %n' ./sioyek-nonstrip
5334000 -- ./sioyek
4977320 -- /usr/bin/sioyek
6619144 -- ./sioyek-nonstrip

Also, when I compared ldd output of the sioyek from the package and the local build, I see a difference in the linked files, the package one doesn't have those libraries:

libQt63DCore.so.6
libQt63DInput.so.6
libQt6Concurrent.so.6
libQt6Svg.so.6

even though all necessary packages are present on the build host.

So in my case there seems to be something wrong with the build host, I'll make a clean build host to try again.

P.S. The LFLAGS are different, but I don't know if that could be the reason for the mislinking.

[vp1981]

I found a workaround to build a working package, but I don't know the real reason for the sioyek crashing.

The Archlinux adds the -Wp,-D_GLIBCXX_ASSERTIONS to CXXFLAGS by default, and this option is the reason why sioyek crashes.

When I build locally with

CXXFLAGS      = -pipe -std=c++17 -march=x86-64 -mtune=generic -O2 -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wp,-D_GLIBCXX_ASSERTIONS -std=gnu++1z -Wall -Wextra -mno-direct-extern-access -D_REENTRANT $(DEFINES)

sioyek crashes. Remove this option and sioyek works fine.

[ahrm]

Unfortunately I can't reproduce the bug event with -Wp,-D_GLIBCXX_ASSERTIONS on ubuntu. I think it is either a compiler bug or some sort of stack corruption (possibly due to using different versions of mupdf, note that the current development version of sioyek is designed for mupdf 1.22 so using version 1.24 might have weird consequences. You can try and link with the version of mupdf included in the repo and see if the bug happens there, adding sioyek_app_image to qmake options will use the included mupdf)

[pmiam]

I encountered this same error with a pdf copy of CFR title 10 by the US NRC. The file is available as a zip archive from the official library at https://www.nrc.gov/reading-rm/doc-collections/cfr/index.html

I am also using the latest sioyek-git from the AUR and I am running the latest Archlinux.

I tried to build from source using build_linux.sh. Unfortunately, I am missing the "lcms2mt.h" header file for the mupdf build. At this point I'm out of my depth and cannot spare much time to learn more, but I wonder if this might have something to do with the size difference vp1981 reported.

[ahrm]

Does the issue happen with the preview release here: https://github.com/ahrm/sioyek/releases/tag/sioyek3-alpha0 (the current preview is incompatible with the previous sioyek local.db and shared.db files, so before running the preview move those files to a different location, otherwise they might be corrupted).

[tokisuno]

https://aur.archlinux.org/packages/sioyek

downloading from this aur package results in the same error on my system. going to try sioyek-git now before building from source.

[tokisuno]

tried with sioyek-git and had the same issue.

[ahrm]

Did you try with the alpha release AppImage that I posted above?

[vp1981]

@tokisuno, I think @ahrm is probably right, the problem is either the tooling or the mupdf version. As I wrote, I found a workaround to build a working package for my Archlinux hosts, but I don't think the sioyek and sioyek-git packages from AUR have the appropriate changes, so they would definitely fail.

P.S. I don't have time to figure out the cause right now, but I suspect the issue might be related to the mupdf library (Archlinux provides version 1.24.9), because Document::count_chapter_pages_accum works with mupdf functions.

[tokisuno]

@vp1981 The appimage seems to be working fine on my Desktop, but I have to try it on my laptop which has the issue.

Is the MuPDF package in Arch ahead or behind what's packaged with sioyek?

[ahrm]

It was ahead, I have recently updated the mupdf in development branch to the same version though.