Dear Maintainer,
* What led up to the situation?
(1) Launch upgraded Handbrake (previously installed on Stretch/v9)
(2) Click "Open Source"; select .mkv file
(3) Select previously created custom preset
(4) Click "Add to Queue"
(5) Click "Start"
* What exactly did you do (or not do) that was effective (or
ineffective)?
(1) ineffective: uninstalled and reinstalled using aptitude
(2) ineffective: deleted ~/.config/ghb, then re-imported custom preset
json
(3) ineffective: queued multiple files
(4) effective: selected built-in preset
* What was the outcome of this action?
Handbrake appears to crash reliably when using this preset.
The preset was created using the previous Handbrake GUI and does not
contain any special arguments, just slider/drop-down selections. (Attached as
default.json)
Encoder log also attached.
* What outcome did you expect instead?
Handbrake should not crash.
Hello Seth Foley, I just tried to reproduce by following your steps. Unfortunately I did not get a crash. Therefore this report might not contain enough information for the maintainers to help. Maybe you could install the package systemd-coredump. In the output of 'journalctl --no-pager' should then the segfaults appear too, followed by a backtrace that you could forward to this bug. Kind regards, Bernhard
Hi Bernhard,
Thank you for the instructions. After additional testing, my initial
report was mistaken; instead, it is probably the selection of a
particular destination folder. When I ask Handbrake to write to my
external (5 TB) disk, connected over USB 2, it crashes with any preset.
However, the backtrace (in /var/lib/systemd/coredump) is ~320 MB. Is
there information I can extract from it, or a particular way I should
make such a large file available?
Output from journalctl --no-pager:
=======================================
Aug 03 09:25:25 sethix kernel: show_signal_msg: 17 callbacks suppressed
Aug 03 09:25:25 sethix kernel: ghb[26263]: segfault at 0 ip
00007f0f9a103fb4 sp 00007f0e81ff14e8 error 4 in
libc-2.28.so[7f0f9a084000+148000]
Aug 03 09:25:25 sethix kernel: Code: 74 12 88 0c 0c 8a 48 03 48 83 c0 04
88 0c 0c f6 c1 ff 75 d2 48 8d 42 fc 66 66 2e 0f 1f 84 00 00 00 00 00 0f
1f 00 48 83 c0 04 <8a> 08 84 0c 0c 74 21 8a 48 01 84 0c 0c 74 16 8a 48
02 84 0c 0c 74
Aug 03 09:25:25 sethix systemd[1]: Created slice
system-systemd\x2dcoredump.slice.
Aug 03 09:25:25 sethix systemd[1]: Started Process Core Dump (PID
26399/UID 0).
Aug 03 09:25:27 sethix systemd-coredump[26400]: Core file was truncated
to 2147483648 bytes.
Aug 03 09:25:28 sethix systemd-coredump[26400]: Process 7024 (ghb) of
user 1000 dumped core.
Stack trace of thread
26263:
#0 0x00007f0f9a103fb4
n/a (n/a)
Aug 03 09:25:28 sethix systemd[1]: systemd-coredump@0-26399-0.service:
Succeeded.
=======================================
Thanks, --SF
Hello Seth Foley,
sorry for the delay.
I guess that "Core file was truncated to 2147483648 bytes." means that
the current configuration probihited to save the whole process.
So first you could try to start handbrake the following way:
ulimit -c 0
handbrake
(That might raise that limit and allows to save a bigger core dump.)
The other guess I have might be to uncomment in /etc/systemd/coredump.conf
the line with ProcessSizeMax and set its value to e.g. 4GB.
Cannot say it that is activated immediately or needs a restart.
If either or both work, then maybe the stack trace in the journal
would reveal some more lines - currently there is just that one
line that points to libc - which is unlikely causing the issue.
Alternatively you might start handbrake like below in a debugger.
Then you don't need to change any system settings, just need ho have
installed the package gdb. That should create a file in you home directory
gdb-handbrake_*.log that you could forward to this bug.
script -a ~/gdb-handbrake_$(date +%Y-%m-%d_%H-%M-%S).log -c "gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'run' -ex 'bt' -ex 'info reg' -ex 'bt full' -ex 'info share' -ex 'detach' -ex 'quit' --args /usr/bin/handbrake"
Kind regards,
Bernhard
Hi Bernhard, I ran `ulimit -c 0` and started handbrake from the Terminal. I added a folder's worth of files to the queue, set the output folder to the 5TB external drive, and clicked Start. Handbrake crashed as expected when starting the second encoding pass. The associated `journalctl --no-pager` output is attached as a text file. The associated core dump is only 34.1 MB this time. Please let me know if there is information I should extract from it, or a separate location where I should upload it. Thanks, --SF
Hello Seth Foley,
if possible you could now install gdb
and the following debug symbol packages.
The latter are stored in a separate
repository, more details in [1]:
handbrake-dbgsym libavformat58-dbgsym
Then if you have not rebooted since the last
handbrake crash, you can use following commands:
coredumpctl list
coredumpctl gdb <PID>
bt
quit
And forward the output again to this bug.
Maybe you want one copy one of the cores in
/var/lib/systemd/coredump/ to a safe place,
because after some time they get automatically deleted.
From your last output I guess something like in [2]
would be produced.
Unfortunately I have not found any bugreport in
the upstream projects.
What I find in the sources it looks like avio_open2
is called with an invalid pointer in filename later,
but maybe the maintainer know something more...
Kind regards,
Bernhard
[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
[2]
Stack trace of thread 25962: |
#0 0x00007f7ce7188fb4 n/a (libc.so.6) | 0x00007ffff32fcfb4 ../sysdeps/x86_64/strspn.S:88
#1 0x00007f7cebc47e73 n/a (libavformat.so.58) | 0x00007ffff7dbbe6e 0x00007ffff7dbbe73 in url_find_protocol at src/libavformat/avio.c:255
#2 0x00007f7cebc48102 n/a (libavformat.so.58) | 0x00007ffff7dbc0fd 0x00007ffff7dbc102 in ffurl_alloc at src/libavformat/avio.c:295
#3 0x00007f7cebc48a2e n/a (libavformat.so.58) | 0x00007ffff7dbca29 0x00007ffff7dbca2e in ffurl_open_whitelist at src/libavformat/avio.c:314
#4 0x00007f7cebc4d187 n/a (libavformat.so.58) | 0x00007ffff7dc1182 0x00007ffff7dc1187 in ffio_open_whitelist at src/libavformat/aviobuf.c:1167
#5 0x00007f7cebc4d1ee avio_open2 (libavformat.so.58) | 0x00007ffff7dc11e9 0x00007ffff7dc11ee in avio_open2 at src/libavformat/aviobuf.c:1181
#6 0x0000561ecd32d8fd n/a (ghb) | 0x000055555561f8f8 0x000055555561f8fd in avformatInit at ../libhb/muxavformat.c:179
#7 0x0000561ecd2e4112 n/a (ghb) | 0x00005555555d6110 0x00005555555d6112 in muxInit at ../libhb/muxcommon.c:649
#8 0x0000561ecd317e56 n/a (ghb) | 0x0000555555609e53 0x0000555555609e56 in do_job at ../libhb/work.c:1758
#9 0x0000561ecd2d607b n/a (ghb) | 0x00005555555c8078 0x00005555555c807b in hb_thread_func at ../libhb/ports.c:867
#10 0x00007f7ce9457fa3 start_thread (libpthread.so.0) | 0x00007ffff55cbfa1 0x00007ffff55cbfa3 in start_thread at pthread_create.c:486
#11 0x00007f7ce71e04cf __clone (libc.so.6) | 0x00007ffff33544cd 0x00007ffff33544cf ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Installed gdb, updated sources, installed the two debug symbol packages, and ran those commands. (I had not rebooted since the crash on Tuesday.) The output of coredumpctl is attached. I also copied the core dump file in case it's wanted later. Thanks, --SF
packages,
Tuesday.)
It is probably /media/<your_user>/<external drive partition label, or
partition UUID> so the output of "lsblk -f" would do.
Or if you selected a subfolder on this external drive partition the
name of this subfolder.
It could be your system encoding is not UTF-8. "locale" command output
in your user session would help. Though debuggus output your system
locale as en_US.UTF-8 so unlikely. Still this output may give a clue.
I believe that handbrake did not support your destination directory
name (or file name) and thus bailed out and the job ended up with no
filenname set as destination. Thus the crash in ffmpeg code.
Or maybe the external drive partition was read only due to an hardware
issue, and handbrake bailed out due to that.
Also the bug may be already fixed (hard to tell without a reproducer),
if you still have the setup could you retry (you can downgrade
handbrake by installing a downloaded buster deb package
at https://packages.debian.org/buster/handbrake then clock on your
architecture). handbrake should not allow a job with a Destination
structure without a File field.
Still it would help a lot to find with which destination folder name it
fails.
Maybe it could get sorted out by reading the source but it will take a
certain amount of time.
my encode log shows a "File" field in the "Destination" structure.
Yours not. It may be why the gdb trace shows a filename=0x0 (ie no
filename) passed to ffmpeg avio_open2.
Mine:
"Destination": {
"AlignAVStart": false,
"ChapterList": [
{
"Name": "Chapter 1"
},
{
"Name": "Chapter 2"
},
{
"Name": "Chapter 3"
} ],
"ChapterMarkers": true,
"File": "/media/prahal/4061-08F6/output_file.mkv",
"InlineParameterSets": false,
"Mp4Options": {
"IpodAtom": false,
"Mp4Optimize": false
},
"Mux": "mkv"
},
Yours:
"Destination": {
"AlignAVStart": false,
"ChapterList": [
{
"Name": "Chapter 1"
},
{
"Name": "Chapter 2"
},
{
"Name": "Chapter 3"
},
{
"Name": "Chapter 4"
},
{
"Name": "Chapter 5"
},
{
"Name": "Chapter 6"
}
],
"ChapterMarkers": true,
"InlineParameterSets": false,
"Mp4Options": {
"IpodAtom": false,
"Mp4Optimize": false
},
"Mux": "mkv"
},
You gdb shows a 0x0 (null) filename passed to the ffmpeg library, which
is likely not supported by this library call, thus that points to an
handbrake bug:
#2 0x00007f7cebc48102 in ffurl_alloc
(puc=0x7f7cd67fa820, filename=0x0, flags=2, int_cb=0x7f7cc19b8708)
at src/libavformat/avio.c:295
#3 0x00007f7cebc48a2e in ffurl_open_whitelist
(puc=puc@entry=0x7f7cd67fa820, filename=<optimized out>,
flags=flags@entry=2, int_cb=<optimized out>, options=options@entry=0x0,
whitelist=whitelist@entry=0x0, blacklist=0x0, parent=0x0) at
src/libavformat/avio.c:314
#4 0x00007f7cebc4d187 in ffio_open_whitelist
(s=0x7f7cc19b8260, filename=<optimized out>, flags=flags@entry=2,
int_cb=<optimized out>, options=options@entry=0x0,
whitelist=whitelist@entry=0x0, blacklist=0x0)
at src/libavformat/aviobuf.c:1167
#5 0x00007f7cebc4d1ee in avio_open2
(s=<optimized out>, filename=<optimized out>, flags=flags@entry=2,
int_cb=<optimized out>, options=options@entry=0x0) at
src/libavformat/aviobuf.c:1181
#6 0x0000561ecd32d8fd in avformatInit (m=0x7f7cc19b7870) at
../libhb/muxavformat.c:179
#7 0x0000561ecd2e4112 in muxInit (muxer=0x7f7cc03ea500,
job=0x7f7cc004a340)
at ../libhb/muxcommon.c:649
#8 0x0000561ecd317e56 in do_job (job=0x7f7cc004a340) at
../libhb/work.c:1758
You also have in your encode.log
[19:00:07] * destination
[19:00:07] + (null)
[19:00:07] + container: Matroska (libavformat)
[19:00:07] + chapter markers
while here I have:
[21:46:17] * destination
[21:46:17] + /media/prahal/4061-08F6/output_file.mkv
[21:46:17] + container: Matroska (libavformat)
[21:46:17] + chapter markers
Note that my encode job output is via handbrake 1.2.2+ds1-1 with its
dependencies mostly downgraded to buster versions. And I cannot
reproduce with by selecting an usb drive with no label but UUID 4061-
08F6 for its partition as handbrake "destination".
Cheers,
Alban
Got the same since the upgrade from 1.6.1+ds1-1 to 1.6.1+ds1-2 (Sid). If I use a built-in preset there is no such problem. Regards Harri
correction: the built-in presets are broken, too. It dies every time. Error message: [Sat Oct 14 17:58:17 2023] handbrake-gtk[52868]: segfault at 18 ip 00007f22a9c337eb sp 00007f2229e5df40 error 4 in libavutil.so.58.2.100[7f22a9c17000+a8000] likely on CPU 4 (core 4, socket 0) [Sat Oct 14 17:58:17 2023] Code: 02 00 e8 a8 39 fe ff e8 e3 3e fe ff 0f 1f 00 f3 0f 1e fa 41 57 49 89 f7 41 56 49 89 fe 41 55 41 54 55 48 89 d5 53 48 83 ec 28 <48> 8b 5f 18 48 89 54 24 08 64 48 8b 04 25 28 00 00 00 48 89 44 24 Regards Harri