MythTV / mythtv

The official MythTV repository

Home Page:https://www.mythtv.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

"stack smashing detected" in mythbackend

MmAaXx500 opened this issue · comments

commented
  • Platform: RaspberryPi OS Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux

  • MythTV version: fixes/33

  • Package version: N/A built from source

  • Component: backend

What steps will reproduce the bug?

I don't have exact steps. Just running it for hours and it happens

How often does it reproduce? Is there a required condition?

I cannot pinpoint any exact action, time, or anything that causes it.

So far I only experienced during live tv

What is the expected behaviour?

Don't smash the stack

What do you see instead?

Sometimes the backend crashes with *** stack smashing detected ***: terminated. I cannot pinpoint any exact action, time, or anything that causes it.

I'd like to note that

  • this build does not have the fstack-protector in place (Qt libs does)
  • MythSocket::IsDataAvailable() is always on the stack (at least on the 2 catched crashes)

Backtraces below. I'm trying to catch it with asan but so far I'm only able to catch a (maybe unrelated) heap-use-after-free (detailed in #769 ).

gdb-bt.txt
valgrind-bt.txt

Additional information

Hardware is a Raspberry Pi 4 (aarch64)

Frontend is Kodi on the same machine.

Exact command I used to build:

../../packaging/deb-light/build_package.sh -c "--cpu=native --disable-firewire --disable-hdhomerun --disable-vbox --disable-ceton --disable-satip --enable-opengl --enable-vulkan --disable-vdpau --disable-vaapi --disable-nvdec --disable-dxva2 --disable-mediacodec --disable-mmal --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libvpx --compile-type=profile"

I have tried with --toolchain=hardened but for 3 days I was unable to catch it. From yesterday I'm trying with --toolchain=hardened + asan but so far only catched a heap-use-after-free (detailed in #769 )

There was a problem that looks similar to what you are reporting now fixed in master a while ago. This fix is now backported in commit 83e1df8 and this might solve the problem.
Same for #769.
Please test.

Most likely the same root cause as #769 which is now fixed. Therefore closing this ticket as well.