handbrake segfaults when using the x265 encoder. ghb[3401]: segfault at 3c0 ip 00000000000003c0 sp 00007fdc6e699518 error 14 in ghb[400000+1c000] likely on CPU 3 (core 3, socket 0) [ 125.519052] Code: Unable to access opcode bytes at 0x396. This bug is also reported on the handbrake forum: https://forum.handbrake.fr/viewtopic.php?p=205914#p205914 and seems to be related to the bundle x265 encoder. Reverting to our non-updated version fixes 1.6.0 fixes the issue. Yet another example of why updates need really bug to be made and not the mere envy of few dreamers :(((
Bug report opened upstream: https://github.com/HandBrake/HandBrake/issues/6006
Assigning the bug to myself, let me carry that pain :)
Assignee: bugsquad => eatdirt
New handbrake build landing in updates_testing (tainted). I have simply updated the bundled x265 encoder to the latest *stable* version and this fixes the segfault. To run tests, please select x265 encoder, and try to run hanbdrake on multiprocessor machines, hyperthreading activated (it seems to be the trigger according to user reports). Thank you. Update advisory: Updated handbrake package to fix x265 errors on multiprocessor encodings. Packages in 9/Tainted/Updates_testing: ======================= handbrake-1.7.3-2.mga9.tainted From SRPMS: handbrake-1.7.3-2.mga9.tainted.src.rpm
CC: (none) => eatdirtAssignee: eatdirt => qa-bugs
Damned: I just realized I've not bumped a subver but a ver. Sorry about that.
Thank you Chris, both for reporting and for the quick remedy. CC previous reporters on Handbrake - can you help test this please?
CC: (none) => Ed_Werder, fri, penguin.sekai+mageiaidentity.writing, wilcal.int
CC: (none) => westel
MGA9-64 Plasma on an HP Pavilion I don't often use x265 at all, as a hardware video player I use often can't use the codec. But, I ran Handbrake from the command line and found the fault. Updated with no issues, then ran handbrake again, running the conversion still in the queue - and again got the failure. FWIW, I also have our x265 from tainted installed. Could it be using that instead of the bundled one mentioned in comment 3?
CC: (none) => andrewsfarm
Tried another video, just in case it was something because the first test used the leftover queue. Same result.
(In reply to Thomas Andrews from comment #6) > > FWIW, I also have our x265 from tainted installed. Could it be using that > instead of the bundled one mentioned in comment 3? No. I removed our x265, and that made no difference. It still segfaults.
Interesting! Could you check you have the right version installed? rpm -i handbrake Please, post the command line command you used, I have only tested with ghb. Thank you!
Sorry: rpm -qi handbrake
(In reply to Thomas Andrews from comment #8) > (In reply to Thomas Andrews from comment #6) > > > > FWIW, I also have our x265 from tainted installed. Could it be using that > > instead of the bundled one mentioned in comment 3? > > No. I removed our x265, and that made no difference. It still segfaults. Upsteram use to make this warning Before updating HandBrake, please make sure there are no pending encodes in the queue, and be sure to make a backup of any custom presets and app preferences you have, as they may not be compatible with newer versions. Tested Before the update the x265 option fail, after the update the conversion finish without issues OK for me
$ rpm -qi handbrake Name : handbrake Version : 1.7.3 Release : 2.mga9.tainted Architecture: x86_64 Install Date: Sat 27 Apr 2024 08:07:50 AM EDT Group : Video/Editors and Converters Size : 63819589 License : GPLv2 Signature : RSA/SHA256, Sat 27 Apr 2024 04:41:12 AM EDT, Key ID b742fa8b80420f66 Source RPM : handbrake-1.7.3-2.mga9.tainted.src.rpm Build Date : Sat 27 Apr 2024 04:28:15 AM EDT Build Host : localhost Packager : eatdirt <eatdirt> Vendor : Mageia.Org URL : https://handbrake.fr/ Summary : An open-source video transcoder Description : HandBrake takes videos you already have and makes new ones that work on your mobile phone, tablet, TV media player, game console, computer, or web browser, nearly anything that supports modern video formats. HandBrake works with most common video files and formats, including ones created by consumer and professional video cameras, mobile devices such as phones and tablets, game and computer screen recordings, and DVD and Blu-ray discs. HandBrake leverages tools such as FFmpeg, x264, and x265 I used ghb on the command line. I also tried using 'Open with' on a video in Dolphin. When I do that it doesn't crash, but doesn't do the encoding, either. More information: This laptop has an AMD A8-4555M APU(4 cores, 4 threads), with HD 7600G graphics. The videos I was trying to transcode use the h264(x264) codec, and are in mp4 containers. Had it worked, the transcoded video would also have been in an mp4 container, with a different name, of course. @katnatek: The first failed attempt after the update was with the leftover queue, but when that didn't work all subsequent trials started with an empty queue. Also, I used whatever came up as the default preset, no customization on this install.
Thanks Thomas! 1) Could you try to encode another video stream with x265 to see if this is related to the video stream? 2) Would it be possible for you to put the video stream triggering the bug online such that I could reproduce? Don't do that, of course, if the video stream violates some patent!!! Then 1) is enough! Cheers, Chris.
MGA9-64 Plasma, i5-7500(4 cores, 4 threads), nvidia Quadro K620 graphics, using nvidia-current. Different system, different source videos, same results. Handbrake crashes both before and after the update when attempting to encode x265 videos. This time I tried mkv containers, no difference. Encoding using x264 works fine.
Ok. Since it works for kanatec and myself, that must be cpu-related, may be some optimization options. What: lscpu is returning? Also, what is the output of: dmesg
Note: It is failing for me on two machines, two different processors(1 AMD, 1 Intel), two different GPUs (1 AMD, 1 nVidia) Could Handbrake be trying to use the GPUs when they don't natively support x265? I'm on the Intel system right now, so... $ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Address sizes: 39 bits physical, 48 bits virtual Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Vendor ID: GenuineIntel Model name: Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz CPU family: 6 Model: 158 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 Stepping: 9 CPU(s) scaling MHz: 21% CPU max MHz: 3800.0000 CPU min MHz: 800.0000 BogoMIPS: 6799.81 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_t sc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault pti ssbd ibrs ibpb stibp tpr_sha dow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dt herm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi md_clear flush_l1d arch_capabilities Virtualization features: Virtualization: VT-x Caches (sum of all): L1d: 128 KiB (4 instances) L1i: 128 KiB (4 instances) L2: 1 MiB (4 instances) L3: 6 MiB (1 instance) NUMA: NUMA node(s): 1 NUMA node0 CPU(s): 0-3 Vulnerabilities: Gather data sampling: Mitigation; Microcode Itlb multihit: KVM: Mitigation: VMX disabled L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled Mds: Mitigation; Clear CPU buffers; SMT disabled Meltdown: Mitigation; PTI Mmio stale data: Mitigation; Clear CPU buffers; SMT disabled Reg file data sampling: Not affected Retbleed: Mitigation; IBRS Spec rstack overflow: Not affected Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Spectre v2: Mitigation; IBRS; IBPB conditional; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected Srbds: Mitigation; Microcode Tsx async abort: Mitigation; TSX disabled dmesg to follow.
Thomas can you rm -rf .config/ghb And test again in both systems? I think could be legacy configuration due upstream recommendations
Created attachment 14517 [details] dmesg after Handbrake failed
(In reply to katnatek from comment #17) > Thomas can you > > rm -rf .config/ghb > > And test again in both systems? > > I think could be legacy configuration due upstream recommendations Didn't help on the Intel system. Last two lines of dmesg after the failure: [ 1341.100927] ghb[91240]: segfault at 3c0 ip 00000000000003c0 sp 00007f9d237fd518 error 14 in ghb[400000+1c000] likely on CPU 3 (core 3, socket 0) [ 1341.100940] Code: Unable to access opcode bytes at 0x396.
Created attachment 14518 [details] Handbrake log of a failed attempt with x265
Created attachment 14519 [details] strace of failed attempt with x265
Installed and tested with out issues. Before the update, handbrake would crash when trying to encode using x265. $ dmesg | grep segfault [26121.471092] ghb[24634]: segfault at 3c0 ip 00000000000003c0 sp 00007f3535ffe518 error 14 in ghb[400000+1c000] likely on CPU 0 (core 0, socket 0) After the update, handbrake no longer crashes and the x265 encoder works correctly. Tried with several video files with out any issues. System: Mageia 9, x86_64, Plasma DE, AMD Ryzen 5 5600G with Radeon Graphics using amdgpu driver. $ uname -a Linux jupiter 6.6.28-desktop-1.mga9 #1 SMP PREEMPT_DYNAMIC Wed Apr 17 17:19:36 UTC 2024 x86_64 GNU/Linux $ rpm -q handbrake handbrake-1.7.3-2.mga9.tainted $ lscpu | grep -i name Model name: AMD Ryzen 5 5600G with Radeon Graphics
CC: (none) => mageia
Please note that the log says of the output: "+ encoder: H.265 (libx265)" Also please note that in the strace a search of "libx265" locates attempts to access several variants, only one of which was actually found, "/lib64/libx265.so.192" Also please note that through all of the failures the installed rpm lib64x265_192 remained unchanged. Am I missing something having to do with libx265 that I'm supposed to have?
Thanks Thomas for all your test. I'll try to reproduce I would say handbrake should not use the system-wide x265, but to be sure ldd /usr/bin/ghb | grep x265 should return nothing. Last thing I could think of, please try to do: ulimit -s unlimited in the same terminal you're going to start handbrake afterwards. Now, I'll git into your logs to see what could possibly go wrong.
Not for i586 why?
my current handbrake: $ rpm -qi handbrake Name : handbrake Version : 1.7.3 Release : 1.mga9.tainted Architecture: x86_64 Install Date: Tue 02 Apr 2024 21:14:55. cannot fault. updated to test package. $ rpm -qi handbrake Name : handbrake Version : 1.7.3 Release : 2.mga9.tainted Architecture: x86_64 Install Date: Sun 28 Apr 2024 10:20:55 cannot fault. System: Kernel: 6.6.22-desktop-1.mga9 arch: x86_64 bits: 64 compiler: gcc v: 12.3.0 Desktop: KDE Plasma v: 5.27.10 tk: Qt v: 5.15.7 wm: kwin_x11 vt: 1 dm: 1: LightDM v: 1.32.0 note: stopped 2: LXDM note: stopped 3: SDDM Distro: Mageia 9 Graphics: Device-1: AMD RV710/M92 [Mobility Radeon HD 4530/4570/5145/530v/540v/545v] vendor: Toshiba driver: radeon v: kernel arch: TeraScale Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 compositor: kwin_x11 driver: X: loaded: radeon,v4l dri: r600 gpu: radeon display-ID: :0 screens: 1
Ok, I can reproduce!!! There is still some issue indeed! I'll investigate, something is going weird on the BS, but I have a tail. I think the version built on our BS is linked to system x265 while it should not.
(In reply to Chris Denice from comment #27) > Ok, I can reproduce!!! There is still some issue indeed! > > I'll investigate, something is going weird on the BS, but I have a tail. I > think the version built on our BS is linked to system x265 while it should > not. $ urpmq --whatrequires lib64x265_192 avidemux-plugins gstreamer1.0-x265 gstreamer1.0-x265 gstreamer1.0-x265 handbrake handbrake lib64avcodec59 lib64avcodec59 lib64heif1 lib64myth33 lib64myth33 lib64x265-devel lib64x265_192 vlc-plugin-common vlc-plugin-common x265 Handbrake requires the library, so it must be using it for something...
Interesting , I have all this packages rpm -qa|grep x265 lib64x265_192-3.4-3.mga9.tainted x265-3.4-3.mga9.tainted gstreamer1.0-x265-1.22.11-1.mga9.tainted And with other video it fails
Unbelievable! This bug might have been there since a while, but only because x265 < 3.6 is bugged, we see it now. The package missed a BuildRequires: git If git is not found, there is no error, but pkg-config misses a configuration file, generated locally by git (+ bundled x265) and silently default to system-wide x265: you get handbrake built with the non-bundled x265 lib. Of course, if system libx265 is faulty, you have handbrake crashing. As such, if you build yourself handbrake locally, and have git installed, you're good. If you build handbrake locally, does not have git installed and have libx265 hanging in /usr/lib64, you get a build generating a buggy handbrake. Only if you miss both git and libx265 you will get a compilation error. I'll push a fix soon.
"Of course, if system libx265 is faulty, you have handbrake crashing." Which, to me anyway, begs the questions, "Then is our libx265 somehow faulty? Faulty in a way that only shows up only under certain conditions?" Chris, I realize from what you have written that you can change Handbrake to not use the system library, and that will address this bug. But, have we uncovered yet another bug that should be addressed?
Let's start again. I have to admit I don't understand why most of the QA testers did not encounter the issue found by Thomas, possibly it is CPU-related. In my case, this was because I was testing with my local build and not the one downloaded from updates_testing. So, please, try again from the new package in updates_testing, and, please Thomas, test again and let us know if this works this time!! ---------------------- Update advisory: Updated handbrake package to fix x265 errors on multiprocessor encodings. Packages in 9/Tainted/Updates_testing: ======================= handbrake-1.7.3-2.1.mga9.tainted From SRPMS: handbrake-1.7.3-2.1.mga9.tainted.src.rpm
@Thomas. Handbrake is using a patched version of x265, so, our system-wide libx265 maybe very fine for other packages but not for handbrake. The dev are probably doing this for optimizing calls that you could not do otherwise. So no worry out of handbrake.
"I have to admit I don't understand why most of the QA testers did not encounter the issue found by Thomas, possibly it is CPU-related." I'm no developer by any stretch of the imagination, nor have I ever claimed to be. But, it just seems strange to me that I would see the same fault on two such widely different cpus (Intel i5-7500 and AMD A8-4555) if the issue was cpu-related. But be that as it may. Tested so far on the Intel machine, because that's the one I happen to be using at the moment. Downloaded with qarepo, and installed without issues. Tested on one of the videos that failed before, a short video taken by me of my brother moving snow with our tractor. Something new this time - I was presented with three H.265 options, H.265, H.265 10-bit, and H.265 12-bit. Before, I did not have the last two choices. All three worked on the video, exactly as they should. Congratulations! I will check with the laptop in a few minutes.
> two such widely different cpus (Intel i5-7500 and AMD A8-4555) Correct, although they are quite of the same age, like mine (Intel(R) Xeon(R) CPU E5-2697 v2). I'd be curious to see the lscpu of other testers. The segfault suggests a call to an optimized instruction, which is not found in the system-wide libx265, as it should.
The HP Pavilion laptop works now, too. The only issue I have with Handbrake on the laptop is that the window is too tall for the 1366x768 display. The bottom part below the progress bar winds up behind the Plasma panel. Seems to be hard-coded somewhere, as the usual size editing tricks just revert back, even editing the size in the ghb preferences file. Oh, well, I don't often use Handbrake on the laptop, as the desktop is much faster, and I can get along with it as it is, so it's a low priority issue for me. I may file another bug on it though, as if a 1366x768 display is all a user has, not seeing the bottom part of the window could be very annoying. I would be OK with sending this on, but we should have a trial from one or two of the other testers, just to be sure this latest version still works for them, too.
Thank you Thomas for the test. Yes, another tester would be welcome to ensure the fix does not trigger a bug for them. For your resolution problem, you could try to reduce the fonts size of your system (handbrake requires a minimal resolution).
I think the issue is more of duration codecs and streams in the video The video that no fail not have sound and is very short The video that fail has audio and is longer @Thomas for the laptop In plasma you can press and hold the "windows" key and press and hold the right button of the mouse and drag the window, for other desktops the first key perhaps is the Alt key at the left (in plasma you can change to use the Alt key instead the windows key) Tested with the video that produce the fail and now works But the question that I do in dev list remains, fetch a remote file at build time fits our guidelines and policies?
I hadn't looked at the Handbrake documentation for years, because it "just worked." Well, I just did, learning that my 10-year-old HP laptop doesn't meet the minimum requirements for either display or cpu. The i5-2500 cpu that was in my desktop until this past January, and worked just fine with Handbrake, didn't meet them, either. The docs do say "While it may be technically possible to run HandBrake on hardware not meeting these requirements, it is not recommended." So I guess I'm just lucky that it worked at all on such antiquated equipment. @katnatek I can change the width, but not the height. One thing that worked some years ago was to set special rules in kwin for Handbrake, but either I've forgotten how (quite possible) or Handbrake simply refuses to change. @Chris changing system font size would change it for everything, and my 75-year-old eyes would not be happy. Better to just use Handbrake on my 1080p desktop monitor - until such time as they force me to buy something new.
>The video that no fail not have sound and is very short Good point, especially because they may not trigger multiprocessing encoding indeed! Your comment is wrong, we do not download anything from the BS because there is no internet on the BS. Now, you can also read the fedora guidelines if you need to complain more about this and enter a fill a bureaucratic fine against the packaging of Handbrake. Or you could just thank me for fixing shits.
> could change it for everything, and my 75-year-old Ah ah, that explains why you were the only one to find the bug in my buggy update. You could teach one or two things to the QA-kids here ;) (I am trolling guys...)
(In reply to Chris Denice from comment #40) > >The video that no fail not have sound and is very short > > Good point, especially because they may not trigger multiprocessing encoding > indeed! > > Your comment is wrong, we do not download anything from the BS because there > is no internet on the BS. Now, you can also read the fedora guidelines if > you need to complain more about this and enter a fill a bureaucratic fine > against the packaging of Handbrake. > Yes I see it now, I also apologize in dev list, just want to know because it's you who lives by the policies ;) > Or you could just thank me for fixing shits. Of course, I thank you, and all who made mageia possible, as much as surly you thank to QA team ;) This looks good enough for me
Whiteboard: (none) => MGA9-64-OK
Keywords: (none) => advisory
(In reply to Thomas Andrews from comment #34) > Tested on one of the videos that failed before, a short video taken by me of > my brother moving snow with our tractor. Something new this time - I was > presented with three H.265 options, H.265, H.265 10-bit, and H.265 12-bit. > Before, I did not have the last two choices. I was also seeing only one H.265 option. The 10-bit and 12-bit were not present. With the most recent update, all three options are present. Retested encoding various videos with x265, including the 10-bit and 12-bit modes, and there were no crashes. An OK for x86_64 seems good to me.
All right, thanks for your test guys!
Testing right know in i586 Before the encoding fail as reported The conversion goes well but is painful slow with the default preset :D The application says it will end in 1hr
(In reply to katnatek from comment #25) > Not for i586 why? Upstream doesn't support it. But we do... MGA9-32 Plasma, AMD Phenom II X4 910, 8GB RAM, AMD HD 8490 graphics, using the server kernel. I didn't want to test this on my real 32-bit hardware, as I don't think it meets the RAM requirements. However, this setup should be enough to let anybody try it if they want to. Qarepo found the rpm with no trouble, and it installed without issue. This was a fresh install this time, not an update. Using the default preset, except for the codec. I converted another video I took a few years back, this time a student hot air balloon pilot using the burner to finish inflating the envelope before a flight. This time Handbrake offered the h.265 option, but not the 10-bit or 12-bit options. The conversion completed without incident, taking about 8 minutes to transcode a 1-minute H.264 video, and vlc reports the result does indeed use the H.265 codec. Looks OK for 32-bits, too
Works good also in i586
Whiteboard: MGA9-64-OK => MGA9-64-OK,MGA9-32-OK
(In reply to Thomas Andrews from comment #46) > (In reply to katnatek from comment #25) > > Not for i586 why? > > Upstream doesn't support it. But we do... > I think was other "The chair issue", but no matter now I perform the test i586 also
Validating.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2024-0136.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED