CRASH - tvh:tcp-start[X]: segfault at X ip X sp X error 4 in tvheadend

P Proton · 2024-09-06T14:04:12+00:00

Hi, I hope someone can help fix what I think is a bug in TVHeadend. I have this crash several times per month. Sometimes when it crashes, it repeatedly cra...

Flole

Any memory corruption should be visible with valgrind.

However, this might be a case where the the "target" for the deliver function is destroyed but it is not removed properly. It will attempt to deliver using freed memory.

spdfrk123456

Hi,
This "remote timeshift" function was implemented to use the timeshift buffer of your HTSP source instead of the normal tvheadend one. It will forward the timeshift command from e.g. Kodi to the source using RTSP commands (using http client).
This was tested on only one provider so I could imagine your provider can give some unexpected results. It should probably be handle better or just disable it for unsupported sources. If you have an example stream I can take a look.

Like Flole mentioned you cannot really use it in a multi user environment as the shifting is done at the remote server, or you might like this behavior 🙂. A workaround would be to create duplicate muxes + channels.

DeltaMikeCharlie

@spdfrk123456 - Thanks for your response.

I was able to recreate the crash that @P Proton experienced by using an IPTV Automatic Network and pointing the URL to the m3u produced by TVH.

http://tvh_ip:9981/playlist

The URLs for the services in the resulting m3u use http as the protocol http://tvh_ip:9981/stream/channelid/84163686?profile=pass.

I am fairly new to IP streaming. Are you suggesting that it is possible to use HTSP as the protocol for streaming from one TVH system to another? If so, are you able to provide an example of the URL or other setup requirements?

spdfrk123456 to use the timeshift buffer of your HTSP source

How did you test this? I would like to try to recreate a functioning system.

DeltaMikeCharlie

It seems that the pointers to the user/password contain garbage leading to a segfault on the following line.

tvheadend/tvheadendblob/55404da6cfd3b0dbbfd5982f87d31dc41f93f509/src/httpc.c#L1223

When Kodi sends the HTSP command to set the playback speed to 0 (pause stream), TVH then tries to send that command to the IPTV source, attempting to send that command to the remote server causes the segmentation fault.

spdfrk123456

DeltaMikeCharlie

Yeah so probably the connection already failed earlier and the client data was freed. We would probably need a stack trace to see from where it's called anyway.
You could also try to debug from higher level first using Wireshark or TCPDump.

spdfrk123456

Please ignore my previous comment.

@DeltaMikeCharlie Yes you are right there will be some random crap in hc. Most likely due to enabling remote timeshift for other sources then RTSP, then iptv_rtsp_start is not called and hc is not initialized.
Probably adding a protocol check somewhere would help, don't know where yet, suggestions are welcome.

@P Proton were you using a RTSP source?

P Proton

spdfrk123456 were you using a RTSP source?

No - The source was a regular IPTV stream from another TVH server that was receiving streams from Satellite. The "Remote Timeshift" check box was enabled in error. The stream never was capable of RTSP.

spdfrk123456 Unfortunate typo from my side there. I meant to say RTSP source. You would need to have service provider who supports things like live tv rewind or cloud recording.

I do actually have an unused encoder capable of outputting RTSP streams. However, I feel we are in a deep grey area right now. Especially as you can't debug it yourself without suitable equipment and I don't have the skills required!

DeltaMikeCharlie I think that the most pragmatic solution would appear to be to disable this feature.

It would be optimal to prevent TVH from crashing, for other users, in this scenario, as I expect others may enable this feature in error. However I can also see that the commit to expand it's description might be a good stop gap pending any further work on that.

Unless anyone has any keen desire to head further down this rabbit hole I would just like to thank everyone for their time and patience whilst we worked through this. We didn't fix the underlying issue but we have identified it and mitigated it with a description. And I will be making a donation to the project in the next 1-2 weeks as a thank you. I hope the funds can help further the project.

spdfrk123456

DeltaMikeCharlie

Unfortunate typo from my side there. I meant to say RTSP source. You would need to have service provider who supports things like live tv rewind or cloud recording.

DeltaMikeCharlie

@P Proton - I think that the most pragmatic solution would appear to be to disable this feature.

spdfrk123456

Yes I don't see an easy way to check from the channel perspective (in code) what mux is used. And with all the type casting and void* it's sometimes hard to tell what is happening.

Probably this should warn people enough: tvheadend/tvheadend1765

spdfrk123456

@P Proton thanks for the understanding.

If somebody is still wants to try more, maybe you could hook one tvheadend server to a second tvheadend server with the SAT>IP server function which also talks RTSP. I didn't look into it much myself though.

« Previous Page