Created attachment 883035 [details] emerge info As per the title, HandBrakeCLI is segfaulting when transcoding an existing file. Used commandline: /usr/bin/HandBrakeCLI -Z "General/Fast 1080p30" -i <input file> -o <output file> (Also fails on profile "General/Fast 720p30") What I'm seeing: HandBrakeCLI is starting up and getting past identifying subtitles, and then immediately segfaults. Running the above with strace doesn't illuminate anything for me. I've downgraded back to 1.5.1-r1 and it's working perfectly. USE flags: U I + - fdk : Support for encoding AAC using media-libs/fdk-aac. - - gstreamer : Support for the streaming media framework from media-libs/gstreamer. + + gtk : Install the GTK UI, ghb. - - numa : Adds support for x265's NUMA capabilities. + - nvenc : Add support for NVIDIA Encoder/Decoder (NVENC/NVDEC) API for hardware accelerated encoding and decoding on NVIDIA cards (requires x11-drivers/nvidia-drivers) + - x265 : Support for encoding h265 using media-libs/x265. emerge info attached - please let me know what else I can supply.
Please capture a backtrace. https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
just curious: Does -9999 work for you? https://handbrake.fr/docs/en/latest/help/activity-log.html describes which files are useful for bug reports on handbrake. We can try to help here, but I think this should finally be reported upstream (if there is not already a ticket) and linked here. https://github.com/HandBrake/HandBrake/issues
ok, I think I followed the backtrace directions properly, re-emerging with CFLAGS="-march=native -Og -ggdb" emerge -1 handbrake and then run against an arbitrarily-chosen file to get the attached gdb.txt. Personally, I don't see anything useful in there. I'll try -9999 as well, otherwise I guess I'll pin at 1.5.1-r1 until the next update.
ah, I can't build 9999: * ERROR: media-video/handbrake-9999::gentoo failed (prepare phase): * patch -p1 failed with /var/tmp/portage/media-video/handbrake-9999/files/handbrake-9999-dont-search-for-python.patch * * Call stack: * ebuild.sh, line 136: Called src_prepare * environment, line 3407: Called default * phase-functions.sh, line 871: Called default_src_prepare * phase-functions.sh, line 947: Called __eapi8_src_prepare * environment, line 539: Called eapply '--' '/var/tmp/portage/media-video/handbrake-9999/files/handbrake-9999-remove-dvdnav-dup.patch' '/var/tmp/portage/media-video/handbrake-9999/files/handbrake-9999-system-tools.patch' '/var/tmp/portage/media-video/handbrake-9999/files/handbrake-9999-dont-search-for-python.patch' '/var/tmp/portage/media-video/handbrake-9999/files/handbrake-1.3.3-x265-link.patch' * environment, line 1603: Called _eapply_patch '/var/tmp/portage/media-video/handbrake-9999/files/handbrake-9999-dont-search-for-python.patch' * environment, line 1541: Called __helpers_die 'patch -p1 failed with /var/tmp/portage/media-video/handbrake-9999/files/handbrake-9999-dont-search-for-python.patch' * isolated-functions.sh, line 112: Called die * The specific snippet of code: * die "$@" * * If you need support, post the output of `emerge --info '=media-video/handbrake-9999::gentoo'`, * the complete build log and the output of `emerge -pqv '=media-video/handbrake-9999::gentoo'`. * The complete build log is located at '/var/tmp/portage/media-video/handbrake-9999/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/media-video/handbrake-9999/temp/environment'. * Working directory: '/var/tmp/portage/media-video/handbrake-9999/work/handbrake-9999' * S: '/var/tmp/portage/media-video/handbrake-9999/work/handbrake-9999' so I guess I'll raise upstream and pin here
Hi, same issue here using the GUI (I launched ghb from the command line) and starting transcoding results in a segmentation fault. In the following what shows me dmesg: > [11218.087397] ghb[657182]: segfault at 377f8334 ip 00007f3b376e0172 sp 00007f3b11bf45e0 error 4 in libc.so.6[7f3b37641000+158000] likely on CPU 3 (core 3, socket 0) > [11218.087421] Code: 16 49 39 c8 0f 8d 73 ff ff ff eb 9c 66 2e 0f 1f 84 00 00 00 00 00 66 90 55 53 48 83 ec 08 48 85 ff 0f 84 c1 00 00 00 48 89 d5 <8b> 57 14 48 89 f8 81 fa 93 f8 ff 7f 0f 8f 8c 00 00 00 8d 8a 6c 07 Iade
Hi, I was traped by the same problem in January. Everything was right till then. So my guess was a change in some other dependencies and i tried downgrading ffmpeg to latest stable pre 6.1 version : 6.0.1-r2 And voila : no need to go down to 1.5 versions of handbrake with ffmpeg-4.4. Everything is doing fine. What does that mean? I cant tell when it exactly happend, but i think it was a change between ffmpeg 6.1.1 and -r1/-r3. I had all those installed and neither did go. Hope this gives some other ideas. Karl
(In reply to Davyd McColl from comment #0) > USE flags: > U I > + - nvenc : Add support for NVIDIA Encoder/Decoder (NVENC/NVDEC) API > for hardware accelerated encoding > and decoding on NVIDIA cards (requires > x11-drivers/nvidia-drivers) Do you have an NVIDIA GPU? I thought enabling hardware acceleration for a not-installed video card was wrong. I rebuilt both media-video/ffpeg and media-video/handbrake disabling the USE flag `nvenc`. Situation did not improve. I still get a segmentation fault when attempting to encode x265.
@Scott: yes, I do have an NVIDIA gpu. I think I've also tried disabling nvenc, but I'll try that again, tho it sounds like it won't make a difference.
(In reply to Davyd McColl from comment #8) > @Scott: yes, I do have an NVIDIA gpu. I think I've also tried disabling > nvenc, but I'll try that again, tho it sounds like it won't make a > difference. I had to throw it out there. I have an ATI card (radeon driver not amdgpu). I guess it was me grasping at straws. I attempted the downgrade of ffmpeg suggested by Karl in comment #6. That also didn't work. Re-reading whole bug report... (In reply to Iade Gesso from comment #5) > In the following what shows me dmesg: > > > [11218.087397] ghb[657182]: segfault at 377f8334 ip 00007f3b376e0172 sp > 00007f3b11bf45e0 error 4 in libc.so.6[7f3b37641000+158000] likely on CPU 3 > (core 3, socket 0) > > [11218.087421] Code: 16 49 39 c8 0f 8d 73 ff ff ff eb 9c 66 2e 0f 1f 84 > 00 00 00 00 00 66 90 55 53 48 83 ec 08 48 85 ff 0f 84 c1 00 00 00 48 89 d5 > <8b> 57 14 48 89 f8 81 fa 93 f8 ff 7f 0f 8f 8c 00 00 00 8d 8a 6c 07 Comment lead me to double check my own dmesg. I found a very similar output. I'm now going through the process of rebuilding packages to ensure everything is working/consistent. This is going to be painful...
Got hit by this bug today and can add some additional info. If I'm reading genlop output right I've been using handbrake 1.6.1 since oct with ffmpeg 6.1 since april and didn't have any issues until after upgrading my profile to 23.0 which I just finished. That would seem to blame the new default use flags? Downgrading to ffmpeg 6.0.1-r4 and re-emerging handbrake-1.6.1 fixed the segfault for me.
Was hit by this too and can confirm that downgrading ffmpeg to 6.0.1 and re-emerging handbrake temporarily solves the issue. Support for ffmpeg versions higher than 6.0.1, including 6.1 and even 7.0, have been added upstream for 1.8.0: https://github.com/HandBrake/HandBrake/pull/5652 https://github.com/HandBrake/HandBrake/pull/5325 Handbrake needs desperately a bump, see bug 917591
