Crash with synctex
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start at the SyncTeX path shown in the backtrace, especially synctex_scanner_parse and _synctex_scan_post_scriptum, and reproduce with the PDF and matching .synctex.gz file. Compare the locally built behavior and reported SyncTeX errors; done means the document no longer crashes or corrupts memory when invalid SyncTeX content is encountered.
Written by the indexing model from the issue text.
Description
* Xreader version (xreader --version)
xreader 3.2.2
* Distribution - (Mint 17.2, Arch, Fedora 25, etc...)
Mint 20.3
Issue
Trying to open a (valid) pdf with additional synctex info results in xreader crashing. Here is the backtrace:
Thread 10 "EvJobScheduler" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fff936d2700 (LWP 14255)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff6dd4859 in __GI_abort () at abort.c:79
#2 0x00007ffff6e3f3ee in __libc_message
(action=action@entry=do_abort, fmt=fmt@entry=0x7ffff6f69285 "%s\n")
at ../sysdeps/posix/libc_fatal.c:155
#3 0x00007ffff6e4747c in malloc_printerr
(str=str@entry=0x7ffff6f6b690 "double free or corruption (!prev)")
at malloc.c:5347
#4 0x00007ffff6e4912c in _int_free
(av=0x7fff84000020, p=0x7fff840e0f90, have_lock=<optimized out>)
at malloc.c:4317
#5 0x00007ffff335f162 in inflateEnd () at /lib/x86_64-linux-gnu/libz.so.1
#6 0x00007ffff3364d59 in gzclose_r () at /lib/x86_64-linux-gnu/libz.so.1
#7 0x00007ffff7f2b818 in _synctex_buffer_get_available_size ()
at /lib/x86_64-linux-gnu/libxreaderdocument.so.3
#8 0x00007ffff7f2bc08 in _synctex_next_line ()
at /lib/x86_64-linux-gnu/libxreaderdocument.so.3
#9 0x00007ffff7f2c730 in _synctex_scan_post_scriptum ()
at /lib/x86_64-linux-gnu/libxreaderdocument.so.3
#10 0x00007ffff7f2ea11 in _synctex_scan_content ()
at /lib/x86_64-linux-gnu/libxreaderdocument.so.3
#11 0x00007ffff7f2f39e in synctex_scanner_parse ()
at /lib/x86_64-linux-gnu/libxreaderdocument.so.3
--Type <RET> for more, q to quit, c to continue without paging--
#12 0x00007ffff7f2f6c8 in synctex_scanner_new_with_output_file () at /lib/x86_64-linux-gnu/libxreaderdocument.so.3
#13 0x00007ffff7f2228a in ev_document_load () at /lib/x86_64-linux-gnu/libxreaderdocument.so.3
#14 0x00007ffff7f2397f in ev_document_factory_get_document () at /lib/x86_64-linux-gnu/libxreaderdocument.so.3
#15 0x00007ffff7f6733c in () at /lib/x86_64-linux-gnu/libxreaderview.so.3
#16 0x00007ffff7f683d2 in () at /lib/x86_64-linux-gnu/libxreaderview.so.3
#17 0x00007ffff7c19ad1 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007ffff3339609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#19 0x00007ffff6ed1293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Steps to reproduce
Try to open the document :)
This is really caused by syntex, renaming the pdf so that there is no corresponding .synctex.gz file lets xreader open it correctly.
Apart from that, reproducibility is a bit tricky, as copying all files to a different folder already "fixes" the crash.
Expected behaviour
I suspect the synctex produced is invalid, but under no circumstances should there be
memory corruption.
Other information
When I build xreader from source locally and try to open the file, there is no crash. Instead it notices errors in synctex:
SyncTeX ERROR: Bad hbox record (2).
SyncTeX ERROR: Bad sheet content.
SyncTeX ERROR: SyncTeX Error: Bad content
- Dominant language
- C
- Stars
- 283
- Forks
- 82
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from linuxmint/xreader
-
Cyrillic homoglyph characters used in place of ASCII <p> tags in Kazakh AppData description string Open
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
Difficulty 3/5 1-2 days Newbie friendliness 48/100
All issues in linuxmint/xreader
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
zephyrproject-rtos/zephyr#119726 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
api7/lua-resty-saml#63 ·
-
[Bounty proposal] fix(web): memory insights count an evening memory on the next day ($25 proposed) Open
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
BasedHardware/omi#15320 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
[adam] AdamNet network read doesn't cap to MAX_ADAM_PACKET_LEN, overflows client receive buffers Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
FujiNetWIFI/fujinet-firmware#1649 · 2 comments ·