search

karlheyes / icecast-kh

KH branch of icecast
GNU General Public License v2.0
298 stars 107 forks source link

KH16 segfault with mount point defining a fallback-mounts #374

Closed patphobos closed 1 year ago

patphobos commented 1 year ago

Hi Karl,

Just tried KH16 today. Icecast KH16 is crashing when a mount point specifying a fallback-mount. Crash is triggered by activity (source connecting, client connecting...). And almost happen immediately when source is always trying to connect. After using git bisecting, it seem the bug has been introduced by [25fd9400a23beb8377b122bcc4d84e63fd925fe2].

gdb backtrace.txt icecast.xml.txt

Test env : Ubuntu Bionic 18.04, automake 2.71 backported.

karlheyes commented 1 year ago

I tagged a 16.1 update on github at https://github.com/karlheyes/icecast-kh/tags

Can you verify that is all working as expected.

karl.

patphobos commented 1 year ago

Hi Karl,

just tried tagged version 16.1 and i'm also hiting the segfault. debug backtrace attached : bt icecast kh16.1.txt configuration : icecast.xml.txt source client seen on the backtrace is Z/IPStream9X2, but not sure it care.

Patrice

karlheyes commented 1 year ago

looks like some optimisations on that build but the info available looks sane. Nothing in the xml looks different to what I test with regularly. Would indicate a cascading issue, ie something happens previously which is having a knock on effect, probably on a codepath with the lock changes. Can you do a make clean debug and add level 4 to logging. send me the error log. If you can run icecast in valgrind (valgrind --out-file=out -v ....icecast -c ....)

karl

patphobos commented 1 year ago

Hi Karl,

code base : kh16.1 tag make clean debug : done errorlog level : 4 valgrind command : valgrind --log-file=out -v ./src/icecast -c /home/patrice/patrice.xml

Icecast seem not to crash when lauched with valgrind. It's may be expected ?

access/error/valgrind/configure logs attached.

Best,

access.log.with-valgrind.not-crashing.txt error.log.without-valgrind.txt error.log.with-valgrind.not-crashing.txt icecast.xml.txt valgrind out.txt access.log.without-valgrind.txt config.log

karlheyes commented 1 year ago

I found the issue on override, a refcounting bug leading to a free up which leads onto bad memory reference.

I've tagged 16.2

patphobos commented 1 year ago

i dont hit the segfault anymore. Fallback seems to work (dit not test fallback-override). But had another issue #375 , probably also linked to lock changes.

many thanks

gunsar commented 1 year ago

I found the issue on override, a refcounting bug leading to a free up which leads onto bad memory reference.

I've tagged 16.2 @karlheyes Pleaser for windows 64 v16.2

karlheyes commented 1 year ago

find the installer at karlheyes.github.io/icecast-2.4.0-kh16.2_win64_setup.exe

karl

gunsar commented 1 year ago

find the installer at karlheyes.github.io/icecast-2.4.0-kh16.2_win64_setup.exe

karl

thanks, I'll try it

gunsar commented 1 year ago

Finally I tried Icecast 2.4.0-16.2 on Linux and Windows I checked /server_version.xsl Linux : Version Icecast 2.4.0-kh16.1 Windows : Version Icecast 2.4.0-kh16.2 Looks like @karlheyes may have forgotten to change the version name for linux, or maybe it's on purpose, because I see that the last change was just a little. I tried the 2 versions above, it still runs normally Thanks very much

gunsar commented 1 year ago

@karlheyes i tried Icecast 2.4.0-kh16.2 on centova, after 6 hours, server went down. tried with Icecast version 2.4.0-kh16.1 running smoothly

BusterNeece commented 1 year ago

@karlheyes Just as a heads-up on this issue, it appears to still be happening in the latest master branch commit of this repo.

Basically, we're noticing that right as a listener connects to listen to a stream that has a relay configured, it triggers a full crash of Icecast. The system is stable right up until someone tries to connect, which, since we have the "always tune into the remote stream even if nobody's listening" setting turned off, suggests that the problem happens when tuning into the remote stream.

karlheyes commented 1 year ago

I've been connecting to the relays quite a few times recently, checking for playback etc. Do you have any log info to show this behaviour. At least to see where it is getting up to and what settings are being employed

karl

karlheyes commented 1 year ago

Anything more on this issue, I've tried an on-demand relay which sounds like your description and it seems to work ok but I don't know what the situation is.

BusterNeece commented 1 year ago

@karlheyes Unfortunately no, from my end as soon as I set the log level higher (to 4) whatever error I was having vanished and now I can't reproduce it on my local installations.

karlheyes commented 1 year ago

ok, it may of been fixed with a commit that you have subsequently updated with. I'll cut a release and if the issue surfaces then let me know.