Bug#931591: Buster: upgraded Handbrake crashes on encode with custom preset
On Wed, 14 Aug 2019 16:38:13 -0700 Seth Foley
wrote:
> 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
Do you by any change know the path name to this external (5 TB) disk ?
It is probably /media// 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 0x7f7cebc48102 in ffurl_alloc
(puc=0x7f7cd67fa820, filename=0x0, flags=2, int_cb=0x7f7cc19b8708)
at src/libavformat/avio.c:295
#3 0x7f7cebc48a2e in ffurl_open_whitelist
(puc=puc@entry=0x7f7cd67fa820, filename=,
flags=flags@entry=2, int_cb=, options=options@entry=0x0,
whitelist=whitelist@entry=0x0, blacklist=0x0, parent=0x0) at
src/libavformat/avio.c:314
#4 0x7f7cebc4d187 in ffio_open_whitelist
(s=0x7f7cc19b8260, filename=, flags=flags@entry=2,
int_cb=, options=options@entry=0x0,
whitelist=whitelist@entry=0x0, blacklist=0x0)
at src/libavformat/aviobuf.c:1167
#5 0x7f7cebc4d1ee in avio_open2
(s=, filename=, flags=flags@entry=2,
int_cb=, options=options@entry=0x0) at
src/libavformat/aviobuf.c:1181
#6 0x561ecd32d8fd in avformatInit (m=0x7f7cc19b7870) at
../libhb/muxavformat.c:179
#7 0x561ecd2e4112 in muxInit (muxer=0x7f7cc03ea500,
job=0x7f7cc004a340)
at ../libhb/muxcommon.c:649
#8 0x561ecd317e56 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
Bug#931591: Buster: upgraded Handbrake crashes on encode with custom preset
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 sfoley@sethix:~$ sudo coredumpctl gdb 25924 PID: 25924 (handbrake) UID: 1000 (sfoley) GID: 1000 (sfoley) Signal: 11 (SEGV) Timestamp: Tue 2019-08-13 16:20:33 PDT (24h ago) Command Line: handbrake Executable: /usr/bin/ghb Control Group: /user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service Unit: user@1000.service User Unit: gnome-terminal-server.service Slice: user-1000.slice Owner UID: 1000 (sfoley) Boot ID: 230bc3d26d844d41ae54905a3ddce9ac Machine ID: bcb68a4cfd884e00a8004c20b2fb56e1 Hostname: sethix Storage: /var/lib/systemd/coredump/core.handbrake.1000.230bc3d26d844d41ae54905a3ddce9ac.25924.156573843300.lz4 Message: Process 25924 (handbrake) of user 1000 dumped core. Stack trace of thread 25962: #0 0x7f7ce7188fb4 n/a (libc.so.6) #1 0x7f7cebc47e73 n/a (libavformat.so.58) #2 0x7f7cebc48102 n/a (libavformat.so.58) #3 0x7f7cebc48a2e n/a (libavformat.so.58) #4 0x7f7cebc4d187 n/a (libavformat.so.58) #5 0x7f7cebc4d1ee avio_open2 (libavformat.so.58) #6 0x561ecd32d8fd n/a (ghb) #7 0x561ecd2e4112 n/a (ghb) #8 0x561ecd317e56 n/a (ghb) #9 0x561ecd2d607b n/a (ghb) #10 0x7f7ce9457fa3 start_thread (libpthread.so.0) #11 0x7f7ce71e04cf __clone (libc.so.6) Stack trace of thread 25926: #0 0x7f7ce71d5819 __poll (libc.so.6) #1 0x7f7ce7479136 n/a (libglib-2.0.so.0) #2 0x7f7ce74794c2 g_main_loop_run (libglib-2.0.so.0) #3 0x7f7ce7acb0d6 n/a (libgio-2.0.so.0) #4 0x7f7ce74a1415 n/a (libglib-2.0.so.0) #5 0x7f7ce9457fa3 start_thread (libpthread.so.0) #6 0x7f7ce71e04cf __clone (libc.so.6) Stack trace of thread 25932: #0 0x7f7ce71ad720 __nanosleep (libc.so.6) #1 0x7f7ce71d8874 usleep (libc.so.6) #2 0x561ecd2cb323 n/a (ghb) #3 0x561ecd2d607b n/a (ghb) #4 0x7f7ce9457fa3 start_thread (libpthread.so.0) #5 0x7f7ce71e04cf __clone (libc.so.6) Stack trace of thread 25933: #0 0x7f7ce71ad720 __nanosleep (libc.so.6) #1 0x7f7ce71d8874 usleep (libc.so.6) #2 0x561ecd2cb323 n/a (ghb) #3 0x561ecd2d607b n/a (ghb) #4 0x7f7ce9457fa3 start_thread (libpthread.so.0) #5 0x7f7ce71e04cf __clone (libc.so.6) Stack trace of thread 25925: #0 0x7f7ce71d5819 __poll (libc.so.6) #1 0x7f7ce7479136 n/a (libglib-2.0.so.0) #2 0x7f7ce747925c g_main_context_iteration (libglib-2.0.so.0) #3 0x7f7ce74792a1 n/a (libglib-2.0.so.0) #4 0x7f7ce74a1415 n/a (libglib-2.0.so.0) #5 0x7f7ce9457fa3 start_thread (libpthread.so.0) #6 0x7f7ce71e04cf __clone (libc.so.6) Stack trace of thread 25924: #0 0x7f7ce7ce4813 n/a (libpango-1.0.so.0) #1 0x7f7ce7ce4a18 n/a (libpango-1.0.so.0) #2 0x7f7ce7ce62e7 pango_itemize_with_base_dir (libpango-1.0.so.0) #3 0x7f7ce7cef40b n/a (libpango-1.0.so.0) #4 0x7f7ce7cf12a2 n/a (libpango-1.0.so.0) #5 0x7f7ce81207c1 gtk_text_layout_get_line_display (libgtk-3.so.0) #6 0x7f7ce8121812 n/a (libgtk-3.so.0) #7 0x7f7ce8101f55 n/a (libgtk-3.so.0) #8 0x7f7ce811f56e gtk_text_layout_validate_yrange (libgtk-3.so.0) #9 0x7f7ce8130ba3 n/a (libgtk-3.so.0) #10 0x7f7ce8131733 n/a (libgtk-3.so.0) #11 0x7f7ce8131b59 n/a (libgtk-3.so.0) #12 0x7f7ce7d43c08 n/a (libgdk-3.so.0) #13 0x7f7ce7478dd8 g_main_context_dispatch (libglib-2.0.so.0) #14 0x7f7ce74791c8 n/a (libglib-2.0.so.0) #15 0x7f7ce747925c g_main_context_iteration (libglib-2.0.so.0) #16 0x7f7ce7a9198d g_application_run (libgio-2.0.so.0) #17 0x561ecd293162 main (ghb) #1
Bug#931591: Buster: upgraded Handbrake crashes on encode with custom preset
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 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 0x7f7ce7188fb4 n/a (libc.so.6)| 0x732fcfb4 ../sysdeps/x86_64/strspn.S:88 #1 0x7f7cebc47e73 n/a (libavformat.so.58)| 0x77dbbe6e 0x77dbbe73 in url_find_protocol at src/libavformat/avio.c:255 #2 0x7f7cebc48102 n/a (libavformat.so.58)| 0x77dbc0fd 0x77dbc102 in ffurl_alloc at src/libavformat/avio.c:295 #3 0x7f7cebc48a2e n/a (libavformat.so.58)| 0x77dbca29 0x77dbca2e in ffurl_open_whitelist at src/libavformat/avio.c:314 #4 0x7f7cebc4d187 n/a (libavformat.so.58)| 0x77dc1182 0x77dc1187 in ffio_open_whitelist at src/libavformat/aviobuf.c:1167 #5 0x7f7cebc4d1ee avio_open2 (libavformat.so.58) | 0x77dc11e9 0x77dc11ee in avio_open2 at src/libavformat/aviobuf.c:1181 #6 0x561ecd32d8fd n/a (ghb) | 0x5561f8f8 0x5561f8fd in avformatInit at ../libhb/muxavformat.c:179 #7 0x561ecd2e4112 n/a (ghb) | 0x555d6110 0x555d6112 in muxInit at ../libhb/muxcommon.c:649 #8 0x561ecd317e56 n/a (ghb) | 0x55609e53 0x55609e56 in do_job at ../libhb/work.c:1758 #9 0x561ecd2d607b n/a (ghb) | 0x555c8078 0x555c807b in hb_thread_func at ../libhb/ports.c:867 #10 0x7f7ce9457fa3 start_thread (libpthread.so.0) | 0x755cbfa1 0x755cbfa3 in start_thread at pthread_create.c:486 #11 0x7f7ce71e04cf __clone (libc.so.6)| 0x733544cd 0x733544cf ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 # Buster/stable amd64 qemu VM 2019-08-14 apt update apt dist-upgrade apt install systemd-coredump gdb mc handbrake handbrake-dbgsym libavformat58-dbgsym apt build-dep handbrake mkdir /home/benutzer/source/handbrake/orig -p cd/home/benutzer/source/handbrake/orig apt source handbrake cd mkdir /home/benutzer/source/ffmpeg/orig -p cd/home/benutzer/source/ffmpeg/orig apt source ffmpeg cd gdb -q --args /usr/bin/handbrake set width 0 set pagination off directory /home/benutzer/source/handbrake/orig/handbrake-1.2.2+ds1/gtk/src directory /home/benutzer/source/ffmpeg/orig/ffmpeg-4.1.3/libavformat directory /home/benutzer/source/handbrake/orig/handbrake-1.2.2+ds1/libhb set backtrace past-main display/i $pc tb main run generate-core-file /tmp/core gdb -q /usr/bin/handbrake --core /tmp/core set width 0 set pagination off directory /home/benutzer/source/handbrake/orig/handbrake-1.2.2+ds1/gtk/src directory /home/benutzer/source/ffmpeg/orig/ffmpeg-4.1.3/libavformat directory /home/benutzer/source/handbrake/orig/handbrake-1.2.2+ds1/libhb set backtrace past-main display/i $pc benutzer@debian:~$ gdb -q /usr/bin/handbrake --core /tmp/core --ex 'batch' --ex 'info target' -ex 'quit' 2>&1 | grep -E ".text$" 0x55584fe0 - 0x55624ea1 is .text gdb -q /usr/bin/handbrake --core /tmp/core --ex 'batch' --ex 'disassemble 0x55584fe0,0x55624ea1' -ex 'quit' 2>&1 | grep -E "07b " -B1 | grep call -A1 # Multiple candidates gdb -q /usr/bin/handbrake --core /tmp/core --ex 'batch' --ex 'disassemble 0x55584fe0,0x55624ea1' -ex 'quit' 2>&1 | grep -E "e56 " -B1 | grep call -A1 # Multiple candidates gdb -q /usr/bin/handbrake --core /tmp/core --ex 'batch' --ex 'disassemble 0x55584fe0,0x55624ea1' -ex 'quit' 2>&1 | grep -E "112 " -B1 | grep call -A1 # Multiple candidates benutzer@debian:~$ gdb -q /usr/bin/handbrake --core /tmp/core --ex 'batch' --ex 'disassemble 0x55584fe0,0x55624ea1' -ex 'quit' 2>&1 | grep -E "avio_open2" -A1 0x5561f8f8 : callq 0x55581be0 0x5561f8fd : test %eax,%eax Stack trace of thread 25962: | #0 0x7f7ce7188fb4 n/a (libc.so.6)| 0x732fcfb4 ../s
Bug#931591: Buster: upgraded Handbrake crashes on encode with custom preset
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
