Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2021-12-17T23:25:49Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2425Don't hardcode the pkg-config architecture, allowing crossbuilds2021-12-17T23:25:49ZUnit 193Don't hardcode the pkg-config architecture, allowing crossbuildsHowdy,
In Debian, there's a concerted effort to ensure crossbuilding works, the person that puts in the most effort on that submitted this patch:
```
Author: Helmut Grohne <helmutg@debian.org>
Description: FTCBFS: m4/shout.m4 hard code...Howdy,
In Debian, there's a concerted effort to ensure crossbuilding works, the person that puts in the most effort on that submitted this patch:
```
Author: Helmut Grohne <helmutg@debian.org>
Description: FTCBFS: m4/shout.m4 hard codes the build architecture pkg-config
ices2 fails to cross build from source, because it uses the build
architecture pkg-config. The cause is a bad macro in m4/shout.m4. After
fixing it, ices2 cross builds successfully. Please consider applying the
attached patch.
.
Note: I had to remove the setting of PKG_CONFIG_PATH, because Debian's
cross wrapper does not work when PKG_CONFIG_PATH is set. Anyway,
/usr/local/lib/pkgconfig is part of the default search path of
pkg-config, so that should not be a problem.
--- ices2-2.0.2.orig/m4/shout.m4
+++ ices2-2.0.2/m4/shout.m4
@@ -19,22 +19,18 @@
# NB: PKG_CHECK_MODULES exits if pkg-config is unavailable on the target
# system, so we can't use it.
-# seed pkg-config with the default libshout location
-PKG_CONFIG_PATH=${PKG_CONFIG_PATH:-/usr/local/lib/pkgconfig}
-export PKG_CONFIG_PATH
-
# Step 1: Use pkg-config if available
-AC_PATH_PROG([PKGCONFIG], [pkg-config], [no])
-if test "$PKGCONFIG" != "no" && `$PKGCONFIG --exists shout`
+PKG_PROG_PKG_CONFIG
+if test "x$PKG_CONFIG" != x && `$PKG_CONFIG --exists shout`
then
- SHOUT_CFLAGS=`$PKGCONFIG --variable=cflags_only shout`
- SHOUT_CPPFLAGS=`$PKGCONFIG --variable=cppflags shout`
- SHOUT_LIBS=`$PKGCONFIG --libs shout`
+ SHOUT_CFLAGS=`$PKG_CONFIG --variable=cflags_only shout`
+ SHOUT_CPPFLAGS=`$PKG_CONFIG --variable=cppflags shout`
+ SHOUT_LIBS=`$PKG_CONFIG --libs shout`
xt_have_shout="maybe"
else
- if test "$PKGCONFIG" != "no"
+ if test "x$PKG_CONFIG" != x
then
- AC_MSG_NOTICE([$PKGCONFIG couldn't find libshout. Try adjusting PKG_CONFIG_PATH.])
+ AC_MSG_NOTICE([$PKG_CONFIG couldn't find libshout. Try adjusting PKG_CONFIG_PATH.])
fi
# pkg-config unavailable, try shout-config
AC_PATH_PROG([SHOUTCONFIG], [shout-config], [no])
```
This technically applies to the m4 module, which is to have issues filed in icecast-server.
Thanks!Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2422Programmatically set the fallback-override value2021-10-31T22:11:44Zisaac-codeProgrammatically set the fallback-override valueAs advised Mr Philip, I am creating this issue.
I have been able to programmatically create a mountpoint and also update the fallback mount on the new online radio I am building.
But after the stream stops the mount switches to the fall...As advised Mr Philip, I am creating this issue.
I have been able to programmatically create a mountpoint and also update the fallback mount on the new online radio I am building.
But after the stream stops the mount switches to the fallback, but immediately the mountpoint is back, I cannot programmatically switch back to the mountpoint
Switching back to the former mountpoint is only possible when the fallback-override value is set to 1, but I cannot achieve that because there is no way to programmatically achieve that, which is weird.
P.S. I want users to create mountpoints via an exposed endpoint, so I don't create it manually inside the icecase.xml filehttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2417After working days without problem Icecast 2.4.4 not trying to update relays ...2022-02-19T09:59:17ZdanielsoheilAfter working days without problem Icecast 2.4.4 not trying to update relays from master serverthis my icecast.xml config:
```
<icecast>
<location>Iran</location>
<admin>info@myts3.ir</admin>
<limits>
<clients>50000</clients>
<sources>1000</sources>
<queue-size>307200</queue-size>
<...this my icecast.xml config:
```
<icecast>
<location>Iran</location>
<admin>info@myts3.ir</admin>
<limits>
<clients>50000</clients>
<sources>1000</sources>
<queue-size>307200</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>600</header-timeout>
<source-timeout>600</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>196608</burst-size>
</limits>
<authentication>
<source-password>removed</source-password>
<relay-password>removed</relay-password>
<admin-user>admin</admin-user>
<admin-password>removed</admin-password>
</authentication>
<hostname>radio.myts3.ir</hostname>
<listen-socket>
<port>18000</port>
</listen-socket>
<http-headers>
<header name="Access-Control-Allow-Origin" value="*" />
</http-headers>
<master-server>192.168.100.53</master-server>
<master-server-port>8000</master-server-port>
<master-update-interval>30</master-update-interval>
<master-password>removed</master-password>
<relays-on-demand>0</relays-on-demand>
<fileserve>1</fileserve>
<paths>
<basedir>/usr/share/icecast</basedir>
<logdir>/var/log/icecast</logdir>
<webroot>/usr/share/icecast/web</webroot>
<adminroot>/usr/share/icecast/admin</adminroot>
<alias source="/" destination="/status-json.xsl"/>
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<loglevel>4</loglevel>
<logsize>100000</logsize>
</logging>
<security>
<chroot>0</chroot>
</security>
</icecast>
```
i have logs too, its 66mB i can't send it here.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2413Latest git server stops responding to HTTP requests and signals with TLS enab...2024-01-20T23:54:15ZRob McAuleyLatest git server stops responding to HTTP requests and signals with TLS enabled after some timeUsing the latest git version of Icecast, every month or two my Icecast server stops responding to HTTP requests and e.g. `kill -hup` / `kill ` signals.
With the logs being set to `WARN`, there is nothing particular in the access or erro...Using the latest git version of Icecast, every month or two my Icecast server stops responding to HTTP requests and e.g. `kill -hup` / `kill ` signals.
With the logs being set to `WARN`, there is nothing particular in the access or error logs. I've set the logs to `DEBUG` now for the next time in hopes of having some more insight.
Some more details:
- The server has between 150-250 listeners per day and 15 sources
- CPU usage is nominal, 0-1%
- RAM usage also nominal, about 50MB (a fresh start is 30MB)
I'm using the latest git so that I can `SIGHUP` the server when I refresh my LetsEncrypt certificates, but the timing of these reloads seems completely disconnected from the server hanging. The timing, at this point, seems random.
I will update this ticket the next time this happens, hopefully with log details.
Please instruct me if there's anything I can do to probe the issue on my end, such as enable particular compile flags for debugging, etc. Also please instruct me if there's any further information you need, such as distribution, GCC version, etc.Icecast 2.5 rc1Rob McAuleyRob McAuleyhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2410URL auth does not work with HTTP/2 servers2023-01-03T10:21:48ZMarvin ScholzURL auth does not work with HTTP/2 serversUsing URL auth with a HTTP/2 capable sever does not work properly:
```text
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "HTTP/2 200 .."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "...Using URL auth with a HTTP/2 capable sever does not work properly:
```text
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "HTTP/2 200 .."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "date: Sun, 25 Apr 2021 11:40:34 GMT.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "server: Apache.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "x-icecast-auth-result: ok.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "x-icecast-auth-alter-action: redirect_permanent.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "x-icecast-auth-alter-argument: https://stream.example.com/hits/highquality.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "content-type: application/json.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: ".."
[2021-04-25 13:40:34] EROR auth_url/handle_returned_header__complete Can not parse auth backend reply.
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2403HTTP 409 on reconnect2024-01-20T23:53:52ZGlenn SimsHTTP 409 on reconnectI recently updated our Icecast software from 2.4.4 to 2.4.99.2 (built via source). The internet at my station goes out sometimes and shuts off the stream. Our program, Broadcast Using This Tool, is designed to automatically reconnect t...I recently updated our Icecast software from 2.4.4 to 2.4.99.2 (built via source). The internet at my station goes out sometimes and shuts off the stream. Our program, Broadcast Using This Tool, is designed to automatically reconnect to the server if the connection dies. However, when the internet comes back on, the log says "server answered with 409!", which means an HTTP conflict.
Icecast is hosted on AWS EC2 running on ports 80 and 443. It is forwarded through my subdomain has an A record with an SSL certificate in the `icecast.xml` file. Since then I have not made any changes to the DNS. This issue had started happening after the upgrade to 2.4.99.2.
This is my BUTT log open in Notepad++ showing the error:
![Screenshot_2020-11-06_191540](/uploads/815c58d23d7cea1510d9fa0184b3d155/Screenshot_2020-11-06_191540.png)Icecast 2.5 rc1Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2401Allow `icy-metadata` and `icy-metaint` in default CORS configuration2022-02-26T18:35:51ZEthan HalsallAllow `icy-metadata` and `icy-metaint` in default CORS configurationI noticed that many of the public streams I've encountered have a wide-open Access-Control-Allow-Origin policy, but do not allow access to request the `Icy-Metadata` header nor allow access to read the `Icy-MetaInt` header in the respons...I noticed that many of the public streams I've encountered have a wide-open Access-Control-Allow-Origin policy, but do not allow access to request the `Icy-Metadata` header nor allow access to read the `Icy-MetaInt` header in the response. This prevents any clients that honor CORS (i.e. browsers) from requesting or reading icy metadata.
This patch is to allow cross-origin access to the `Icy-MetaData` and `Icy-MetaInt` headers by default. Also, this patch inserts the `Access-Control-Allow-Headers` and `Access-Control-Expose-Headers` into the default XML configuration so that icy metadata works by default. Users can opt-out of it like they can with `Access-Control-Allow-Origin: *`.
The main use-case is to enable browsers to read icy metadata via a cross-origin request. I'm building a client side library that does that here: [icecast-metadata-js](https://github.com/eshaz/icecast-metadata-js). The inline metadata offers immediate metadata updates with no noticeable latency, which is really valuable in certain contexts, like for broadcasting police / fire scanner metadata, or ad insertions, etc.
[0001-feat-add-icy-metadata-support-for-cors.patch](/uploads/fb696baa19b3dfe8419021d66d52e2a3/0001-feat-add-icy-metadata-support-for-cors.patch)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2400global stats key listeners incorrect after client got dropped from pending_tr...2021-03-22T23:22:29ZPhilipp Schafftglobal stats key listeners incorrect after client got dropped from pending_tree for max_listenersThe global stats key `listeners` is incorrect after a client is dropped from the `pending_tree` as the mount is full. this happens on client move (as per admin request or fallback).
The code can be found looking in source.c for:
```
...The global stats key `listeners` is incorrect after a client is dropped from the `pending_tree` as the mount is full. this happens on client move (as per admin request or fallback).
The code can be found looking in source.c for:
```
ICECAST_LOG_INFO("Client deleted, exceeding maximum listeners for this "
"mountpoint (%s).", source->mount);
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2397Streamers get kicked upon DJ connection.2020-10-16T15:25:20ZCallum OKaneStreamers get kicked upon DJ connection.Hey, on my radioserver, running Icecast 2, whenever a streamer connects, all the listeners are disconnected from the stream. This only happens for some DJ's using software like VirtualDJ which many of ours do. We drop almost 100 listener...Hey, on my radioserver, running Icecast 2, whenever a streamer connects, all the listeners are disconnected from the stream. This only happens for some DJ's using software like VirtualDJ which many of ours do. We drop almost 100 listeners, and this is quite frustrating, anyone able to help?https://gitlab.xiph.org/xiph/icecast-server/-/issues/2392Tag for 2.4.4 is missing2024-01-06T20:01:19ZDavid RungeTag for 2.4.4 is missingHi! I package icecast for Arch Linux.
We currently use tarballs from this location: https://www.icecast.org/download/
However, the release for 2.4.4 is not reflected in a tag in this repository: https://gitlab.xiph.org/xiph/icecast-serv...Hi! I package icecast for Arch Linux.
We currently use tarballs from this location: https://www.icecast.org/download/
However, the release for 2.4.4 is not reflected in a tag in this repository: https://gitlab.xiph.org/xiph/icecast-server/-/tags
It would be very awesome if you could add the tag so that reproducibility can be ensured.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2391Found memory leak problems on ubuntu 20.04 tls2024-01-21T02:16:55ZChaichanaFound memory leak problems on ubuntu 20.04 tlsubuntu 20.04tls icecast2 use abnormal memory, unlike ubuntu 18.04 that doesn't use memory much
Must use the command service icecast2 restart memory to return to normal But before long, it will be leak same.
- Installation of all applica...ubuntu 20.04tls icecast2 use abnormal memory, unlike ubuntu 18.04 that doesn't use memory much
Must use the command service icecast2 restart memory to return to normal But before long, it will be leak same.
- Installation of all applications
https://mediarealm.com.au/articles/icecast-https-ssl-setup-lets-encrypt/
- IMAGE
Top in image ubuntu 18.04 tls
Bottom in image ubuntu 20.04 tls
![ฟ](/uploads/d236d04fa7fc56f7c97c7d47e7937a12/ฟ.jpg)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2389Infinite loop login/passwd when htpasswd is used2020-10-26T17:36:34ZtormyvancoolInfinite loop login/passwd when htpasswd is usedSetting up **Icecast 2.4.4** Windows version (**W7 64bit** and **HTTP** protocol (I don't use HTTPS)) I got a strange issue, not reported by the error.log
The created user, gets an infinite loop of LOGIN popups.
Writing the correct logi...Setting up **Icecast 2.4.4** Windows version (**W7 64bit** and **HTTP** protocol (I don't use HTTPS)) I got a strange issue, not reported by the error.log
The created user, gets an infinite loop of LOGIN popups.
Writing the correct login and password, the popup is always returned and the user never get access.
Even giving to the user a login string as http://user:password@My_Public_Ip:8000/stream (where **/stream** is my mountpoint)
- 8000 is the port I use
- It's opened in bidirectional way on my router and firewall
- protocols: TCP/UDP
Please here below just the lines for the auth
in attachment ou find my *icecast.xml* "anonymized", as requested by your Policies, and the chunck of the *error.log* where I got the infinite loop
It resulted impossible to use Login and Password (at the moment).
Users should be very limited, that's why I put just 3
The MyAuth file is correctly generated and managed bui the UI
```
<!-- Normal mounts -->
<mount type="normal">
<mount-name>/stream</mount-name>
<max-listeners>3</max-listeners>
<authentication type="htpasswd">
<option name="filename" value="myauth"/>
<option name="allow_duplicate_users" value="0"/>
</authentication>
</mount>
```
[icecast.xml](/uploads/48fd92adae020bc51b2ab90b14e816c4/icecast.xml)
[error.log](/uploads/debf531d6f79a2f2cfd0d73f9789a687/error.log)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2387listclients not working if authentication type is url2020-10-15T10:35:27Znaitsirchlistclients not working if authentication type is urlWe have configured our Icecast (v. 2.4.4) mount with stream_auth via URL. Authentication with the source client works well. But it is comming to a strange error when listener stats are requested with the source password.
This is our mou...We have configured our Icecast (v. 2.4.4) mount with stream_auth via URL. Authentication with the source client works well. But it is comming to a strange error when listener stats are requested with the source password.
This is our mount config:
```xml
<mount type="default">
<mount-name>/stream</mount-name>
<stream-name><![CDATA[Test]]></stream-name>
<authentication type="url">
<option name="auth_header" value="icecast-auth-user: 1"/>
<option name="stream_auth" value="https://my-authentication-provider.com/api/icecast/stream_auth"/>
</authentication>
</mount>
```
Streaming with butt and source password works as expected. So the authentication works.
Now, if I try to access the URL `/admin/listclients?mount=/stream` with the source password, to see the number of connected listeners. I get a *403 Forbidden* with the message `Mountpoint in use`.
This is the request that is sent by curl:
```
GET /admin/listclients?mount=/stream HTTP/1.1
Host: server34299.streamplus.de:10106
Authorization: Basic {...}
User-Agent: curl/7.64.0
Accept: */*
```
I have checked the base64 encoded username and password in the authentication header. It is the same that is used in the source client.
The response by Icecast is:
```
HTTP/1.0 403 Forbidden
Server: Icecast 2.4.4
Connection: Close
Date: Wed, 17 Jun 2020 11:58:06 GMT
Content-Type: text/plain; charset=utf-8
Cache-Control: no-cache, no-store
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Pragma: no-cache
Mountpoint in use
```
If I remove the `<authentication type="url">` part of the config and restart the server, calling `/admin/listclients?mount=/stream` works as expected.
It looks like the listclients action has a bug if Icecast is running with stream_auth via URL. If you need any further information please let me know.
OS: Debian 10.4, Linux version 4.19.0-9-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07)
**Update:**
If I use the admin credentials to access the listener stats, it works as expected.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2383Oversized EBML headers for WebM live stream2022-03-09T19:32:39ZWolne WilnoOversized EBML headers for WebM live streamFrom version ffmpeg 4.1 or above, when trying to stream WebM video Icecast produce error: `EBML Header too large, failing`
Solution is to increase EBML Header in `format_ebml.c` from 131072 bytes (0.125 MiB) to bytes 524288 (0.5 Mib)
C...From version ffmpeg 4.1 or above, when trying to stream WebM video Icecast produce error: `EBML Header too large, failing`
Solution is to increase EBML Header in `format_ebml.c` from 131072 bytes (0.125 MiB) to bytes 524288 (0.5 Mib)
Change in https://gitlab.xiph.org/xiph/icecast-server/-/blob/master/src/format_ebml.c from `#define EBML_HEADER_MAX_SIZE 131072` to `#define EBML_HEADER_MAX_SIZE 524288`https://gitlab.xiph.org/xiph/icecast-server/-/issues/2379Consider adding fallback support for WolfSSL2024-01-21T02:16:56ZUnit 193Consider adding fallback support for WolfSSLHowdy,
WolfSSL has an OpenSSL compatibility layer, so if a distribution can't offer Icecast linked with OpenSSL, using WolfSSL might be a possibility. I've made and tested a minimal patch, and with git master of WolfSSL Icecast is full...Howdy,
WolfSSL has an OpenSSL compatibility layer, so if a distribution can't offer Icecast linked with OpenSSL, using WolfSSL might be a possibility. I've made and tested a minimal patch, and with git master of WolfSSL Icecast is fully functional.
Would you consider adding support for it? It was mentioned that this might be more fitting for the 2.4 series.
Example patch attached (note this is not the version I was testing).
[icecast-wolfssl.patch](/uploads/5690621487ec0fc7ee689d161032b5ef/icecast-wolfssl.patch)
~Unit 193Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2378There should be a stats value indicating how if a stream is in a stable state2022-02-27T20:06:54ZPhilipp SchafftThere should be a stats value indicating how if a stream is in a stable stateThere should be a stats value that indicates if a stream has been proven stable. That is at least connected for a given minimum amount of time and sending data. This could be used by the fallback logic to avoid switching 'back' to a flap...There should be a stats value that indicates if a stream has been proven stable. That is at least connected for a given minimum amount of time and sending data. This could be used by the fallback logic to avoid switching 'back' to a flapping stream.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2375Cross-Origin Preflight OPTIONS sends 4012023-03-06T15:12:48ZBradley HiltonCross-Origin Preflight OPTIONS sends 401When a browser does a cross-origin request with preflight, icecast server fails with `401 Authentication Required` when there is no way to include the user credentials.
https://www.w3.org/TR/cors/#preflight-requestWhen a browser does a cross-origin request with preflight, icecast server fails with `401 Authentication Required` when there is no way to include the user credentials.
https://www.w3.org/TR/cors/#preflight-requesthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2371Memory leaked due during source timeouts2019-04-01T12:52:31ZThomas B. RückerMemory leaked due during source timeouts```
==4664== Memcheck, a memory error detector
==4664== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4664== Using Valgrind-3.14.0-3a3000290b-20181009X and LibVEX; rerun with -h for copyright info
==4664== Command: ic...```
==4664== Memcheck, a memory error detector
==4664== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4664== Using Valgrind-3.14.0-3a3000290b-20181009X and LibVEX; rerun with -h for copyright info
==4664== Command: icecast -c /etc/icecast.xml
==4664== Parent PID: 4663
==4664==
--4664--
--4664-- Valgrind options:
--4664-- --log-file=valgrind.log
--4664-- -v
--4664-- --tool=memcheck
--4664-- --leak-check=yes
--4664-- --show-reachable=yes
--4664-- --num-callers=20
--4664-- --track-fds=yes
--4664-- Contents of /proc/version:
--4664-- Linux version 4.19.3 (xogium@C2ArchLinux) (gcc version 8.2.0 (GCC)) #2 SMP PREEMPT Thu Nov 22 15:00:50 EST 2018
--4664--
--4664-- Arch and hwcaps: ARM64, LittleEndian, baseline
--4664-- Page sizes: currently 4096, max supported 65536
--4664-- Valgrind library directory: /usr/lib/valgrind
--4664-- Reading syms from /usr/bin/icecast
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/ld-2.28.so
--4664-- Reading syms from /usr/lib/valgrind/memcheck-arm64-linux
--4664-- object doesn't have a dynamic symbol table
--4664-- Scheduler: using generic scheduler lock implementation.
--4664-- Reading suppressions file: /usr/lib/valgrind/default.supp
==4664== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-4664-by-root-on-???
==4664== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-4664-by-root-on-???
==4664== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-4664-by-root-on-???
==4664==
==4664== TO CONTROL THIS PROCESS USING vgdb (which you probably
==4664== don't want to do, unless you know exactly what you're doing,
==4664== or are doing some strange experiment):
==4664== /usr/lib/valgrind/../../bin/vgdb --pid=4664 ...command...
==4664==
==4664== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==4664== /path/to/gdb icecast
==4664== and then give GDB the following command
==4664== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=4664
==4664== --pid is optional if only one valgrind process is running
==4664==
--4664-- REDIR: 0x40175c0 (ld-linux-aarch64.so.1:strlen) redirected to 0x580c8c94 (vgPlain_arm64_linux_REDIR_FOR_strlen)
--4664-- REDIR: 0x4017300 (ld-linux-aarch64.so.1:strcmp) redirected to 0x580c8ce8 (vgPlain_arm64_linux_REDIR_FOR_strcmp)
--4664-- REDIR: 0x40171f0 (ld-linux-aarch64.so.1:index) redirected to 0x580c8cbc (vgPlain_arm64_linux_REDIR_FOR_index)
--4664-- Reading syms from /usr/lib/valgrind/vgpreload_core-arm64-linux.so
--4664-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so
--4664-- Reading syms from /usr/lib/libssl.so.1.1
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libcurl.so.4.5.0
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libspeex.so.1.5.1
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libtheora.so.0.3.10
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libvorbis.so.0.4.8
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libxslt.so.1.1.32
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libxml2.so.2.9.8
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/liboggkate.so.1.2.2
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libkate.so.1.3.0
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libogg.so.0.8.3
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libpthread-2.28.so
--4664-- Reading syms from /usr/lib/libc-2.28.so
--4664-- Reading syms from /usr/lib/libcrypto.so.1.1
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libnghttp2.so.14.17.1
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libidn2.so.0.3.4
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libssh2.so.1.0.1
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libpsl.so.5.3.1
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libgssapi_krb5.so.2.2
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libkrb5.so.3.3
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libk5crypto.so.3.1
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libcom_err.so.2.1
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libz.so.1.2.11
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libm-2.28.so
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libdl-2.28.so
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libicuuc.so.63.1
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/liblzma.so.5.2.4
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libunistring.so.2.1.0
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libkrb5support.so.0.1
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libkeyutils.so.1.8
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libresolv-2.28.so
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libicudata.so.63.1
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libstdc++.so.6.0.25
--4664-- Reading syms from /usr/lib/libgcc_s.so.1
--4664-- REDIR: 0x4d40990 (libc.so.6:memcpy) redirected to 0x484d1c0 (memcpy)
--4664-- REDIR: 0x4d3f0d0 (libc.so.6:rindex) redirected to 0x484b040 (rindex)
--4664-- REDIR: 0x4d3a5b0 (libc.so.6:malloc) redirected to 0x48480a0 (malloc)
--4664-- REDIR: 0x4d3ebc0 (libc.so.6:strlen) redirected to 0x484b678 (strlen)
--4664-- REDIR: 0x4d3e380 (libc.so.6:strcmp) redirected to 0x484c840 (strcmp)
--4664-- REDIR: 0x4d3f058 (libc.so.6:strncpy) redirected to 0x484b950 (strncpy)
--4664-- REDIR: 0x4d3b3c8 (libc.so.6:calloc) redirected to 0x484a3c0 (calloc)
--4664-- REDIR: 0x4d3fb08 (libc.so.6:strstr) redirected to 0x4850600 (strstr)
--4664-- REDIR: 0x4d3ffd0 (libc.so.6:memchr) redirected to 0x484ca20 (memchr)
--4664-- REDIR: 0x4d42350 (libc.so.6:strchrnul) redirected to 0x484fde0 (strchrnul)
--4664-- REDIR: 0x4d407e0 (libc.so.6:strncasecmp) redirected to 0x484c1c0 (strncasecmp)
--4664-- REDIR: 0x4d3ac10 (libc.so.6:free) redirected to 0x4849270 (free)
--4664-- REDIR: 0x4d3ee9c (libc.so.6:strncmp) redirected to 0x484bef0 (strncmp)
--4664-- REDIR: 0x4d3e270 (libc.so.6:index) redirected to 0x484b1f0 (index)
--4664-- REDIR: 0x4d403d8 (libc.so.6:mempcpy) redirected to 0x484fee0 (mempcpy)
--4664-- REDIR: 0x4d40540 (libc.so.6:stpcpy) redirected to 0x484ec60 (stpcpy)
--4664-- Reading syms from /usr/lib/libnss_files-2.28.so
--4664-- object doesn't have a symbol table
--4664-- REDIR: 0x4d3e480 (libc.so.6:strcpy) redirected to 0x484b790 (strcpy)
--4664-- REDIR: 0x4d40200 (libc.so.6:memset) redirected to 0x484f308 (memset)
--4664-- REDIR: 0x4d3ae60 (libc.so.6:realloc) redirected to 0x484a5f0 (realloc)
--4664-- REDIR: 0x4d40780 (libc.so.6:strcasecmp) redirected to 0x484c0f0 (strcasecmp)
--4664-- REDIR: 0x4d400c0 (libc.so.6:bcmp) redirected to 0x484eaf0 (bcmp)
--4664-- REDIR: 0x4d40980 (libc.so.6:memmove) redirected to 0x484f3d0 (memmove)
--4664-- REDIR: 0x4da1f28 (libc.so.6:__memcpy_chk) redirected to 0x48504f8 (__memcpy_chk)
--4664-- REDIR: 0x4da1f48 (libc.so.6:__memmove_chk) redirected to 0x484fd68 (__memmove_chk)
--4664-- Reading syms from /usr/lib/libnss_mdns_minimal.so.2
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libnss_dns-2.28.so
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libnss_mymachines.so.2
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/librt-2.28.so
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libcap.so.2.26
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libmount.so.1.1.0
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libblkid.so.1.1.0
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libuuid.so.1.3.0
--4664-- object doesn't have a symbol table
--4664-- Reading syms from /usr/lib/libnss_myhostname.so.2
--4664-- object doesn't have a symbol table
--4664-- Discarding syms at 0x788c150-0x78933ec in /usr/lib/libnss_files-2.28.so (have_dinfo 1)
--4664-- Discarding syms at 0x7fb3ee0-0x7fb5584 in /usr/lib/libnss_mdns_minimal.so.2 (have_dinfo 1)
--4664-- Discarding syms at 0x7fc8e90-0x7fcbc30 in /usr/lib/libnss_dns-2.28.so (have_dinfo 1)
==4664==
==4664== FILE DESCRIPTORS: 4 open at exit.
==4664== Open file descriptor 3: /home/xogium/valgrind.log
==4664== <inherited from parent>
==4664==
==4664== Open file descriptor 2: /dev/pts/3
==4664== <inherited from parent>
==4664==
==4664== Open file descriptor 1: /dev/pts/3
==4664== <inherited from parent>
==4664==
==4664== Open file descriptor 0: /dev/pts/3
==4664== <inherited from parent>
==4664==
==4664==
==4664== HEAP SUMMARY:
==4664== in use at exit: 418,488 bytes in 84 blocks
==4664== total heap usage: 13,504 allocs, 13,420 frees, 5,094,700 bytes allocated
==4664==
==4664== Searching for pointers to 84 not-freed blocks
==4664== Checked 372,232 bytes
==4664==
==4664== 64 bytes in 2 blocks are still reachable in loss record 1 of 11
==4664== at 0x4848114: malloc (vg_replace_malloc.c:299)
==4664== by 0x4017557: strdup (in /usr/lib/ld-2.28.so)
==4664== by 0x4013CCF: _dl_load_cache_lookup (in /usr/lib/ld-2.28.so)
==4664== by 0x4008317: _dl_map_object (in /usr/lib/ld-2.28.so)
==4664== by 0x401197B: dl_open_worker (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x4011537: _dl_open (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCF05B: do_dlopen (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCFC77: _dl_catch_error (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCF16B: dlerror_run (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCF21B: __libc_dlopen_mode (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB6667: nss_load_library (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB6F27: __nss_lookup_function (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB7183: __nss_next2 (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB772B: __nss_endent (in /usr/lib/libc-2.28.so)
==4664== by 0x4DA6EFF: endhostent (in /usr/lib/libc-2.28.so)
==4664== by 0x11488F: ??? (in /usr/bin/icecast)
==4664==
==4664== 64 bytes in 2 blocks are still reachable in loss record 2 of 11
==4664== at 0x4848114: malloc (vg_replace_malloc.c:299)
==4664== by 0x400A997: _dl_new_object (in /usr/lib/ld-2.28.so)
==4664== by 0x400580F: _dl_map_object_from_fd (in /usr/lib/ld-2.28.so)
==4664== by 0x4008157: _dl_map_object (in /usr/lib/ld-2.28.so)
==4664== by 0x401197B: dl_open_worker (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x4011537: _dl_open (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCF05B: do_dlopen (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCFC77: _dl_catch_error (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCF16B: dlerror_run (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCF21B: __libc_dlopen_mode (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB6667: nss_load_library (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB6F27: __nss_lookup_function (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB7183: __nss_next2 (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB772B: __nss_endent (in /usr/lib/libc-2.28.so)
==4664== by 0x4DA6EFF: endhostent (in /usr/lib/libc-2.28.so)
==4664== by 0x11488F: ??? (in /usr/bin/icecast)
==4664==
==4664== 109 bytes in 5 blocks are still reachable in loss record 3 of 11
==4664== at 0x4848114: malloc (vg_replace_malloc.c:299)
==4664== by 0x4017557: strdup (in /usr/lib/ld-2.28.so)
==4664== by 0x4013CCF: _dl_load_cache_lookup (in /usr/lib/ld-2.28.so)
==4664== by 0x4008317: _dl_map_object (in /usr/lib/ld-2.28.so)
==4664== by 0x400BED7: openaux (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x400C1F7: _dl_map_object_deps (in /usr/lib/ld-2.28.so)
==4664== by 0x40119C3: dl_open_worker (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x4011537: _dl_open (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCF05B: do_dlopen (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCFC77: _dl_catch_error (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCF16B: dlerror_run (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCF21B: __libc_dlopen_mode (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB6667: nss_load_library (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB6F27: __nss_lookup_function (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB7183: __nss_next2 (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB772B: __nss_endent (in /usr/lib/libc-2.28.so)
==4664== by 0x4DA6EFF: endhostent (in /usr/lib/libc-2.28.so)
==4664==
==4664== 109 bytes in 5 blocks are still reachable in loss record 4 of 11
==4664== at 0x4848114: malloc (vg_replace_malloc.c:299)
==4664== by 0x400A997: _dl_new_object (in /usr/lib/ld-2.28.so)
==4664== by 0x400580F: _dl_map_object_from_fd (in /usr/lib/ld-2.28.so)
==4664== by 0x4008157: _dl_map_object (in /usr/lib/ld-2.28.so)
==4664== by 0x400BED7: openaux (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x400C1F7: _dl_map_object_deps (in /usr/lib/ld-2.28.so)
==4664== by 0x40119C3: dl_open_worker (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x4011537: _dl_open (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCF05B: do_dlopen (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCFC77: _dl_catch_error (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCF16B: dlerror_run (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCF21B: __libc_dlopen_mode (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB6667: nss_load_library (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB6F27: __nss_lookup_function (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB7183: __nss_next2 (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB772B: __nss_endent (in /usr/lib/libc-2.28.so)
==4664== by 0x4DA6EFF: endhostent (in /usr/lib/libc-2.28.so)
==4664==
==4664== 1,728 bytes in 7 blocks are still reachable in loss record 5 of 11
==4664== at 0x484A464: calloc (vg_replace_malloc.c:752)
==4664== by 0x400F1B3: _dl_check_map_versions (in /usr/lib/ld-2.28.so)
==4664== by 0x40119FB: dl_open_worker (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x4011537: _dl_open (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCF05B: do_dlopen (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCFC77: _dl_catch_error (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCF16B: dlerror_run (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCF21B: __libc_dlopen_mode (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB6667: nss_load_library (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB6F27: __nss_lookup_function (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB7183: __nss_next2 (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB772B: __nss_endent (in /usr/lib/libc-2.28.so)
==4664== by 0x4DA6EFF: endhostent (in /usr/lib/libc-2.28.so)
==4664== by 0x11488F: ??? (in /usr/bin/icecast)
==4664==
==4664== 2,382 bytes in 2 blocks are still reachable in loss record 6 of 11
==4664== at 0x484A464: calloc (vg_replace_malloc.c:752)
==4664== by 0x400A727: _dl_new_object (in /usr/lib/ld-2.28.so)
==4664== by 0x400580F: _dl_map_object_from_fd (in /usr/lib/ld-2.28.so)
==4664== by 0x4008157: _dl_map_object (in /usr/lib/ld-2.28.so)
==4664== by 0x401197B: dl_open_worker (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x4011537: _dl_open (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCF05B: do_dlopen (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCFC77: _dl_catch_error (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCF16B: dlerror_run (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCF21B: __libc_dlopen_mode (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB6667: nss_load_library (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB6F27: __nss_lookup_function (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB7183: __nss_next2 (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB772B: __nss_endent (in /usr/lib/libc-2.28.so)
==4664== by 0x4DA6EFF: endhostent (in /usr/lib/libc-2.28.so)
==4664== by 0x11488F: ??? (in /usr/bin/icecast)
==4664==
==4664== 5,904 bytes in 5 blocks are still reachable in loss record 7 of 11
==4664== at 0x484A464: calloc (vg_replace_malloc.c:752)
==4664== by 0x400A727: _dl_new_object (in /usr/lib/ld-2.28.so)
==4664== by 0x400580F: _dl_map_object_from_fd (in /usr/lib/ld-2.28.so)
==4664== by 0x4008157: _dl_map_object (in /usr/lib/ld-2.28.so)
==4664== by 0x400BED7: openaux (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x400C1F7: _dl_map_object_deps (in /usr/lib/ld-2.28.so)
==4664== by 0x40119C3: dl_open_worker (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x4011537: _dl_open (in /usr/lib/ld-2.28.so)
==4664== by 0x4DCF05B: do_dlopen (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCFBC7: _dl_catch_exception (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCFC77: _dl_catch_error (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCF16B: dlerror_run (in /usr/lib/libc-2.28.so)
==4664== by 0x4DCF21B: __libc_dlopen_mode (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB6667: nss_load_library (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB6F27: __nss_lookup_function (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB7183: __nss_next2 (in /usr/lib/libc-2.28.so)
==4664== by 0x4DB772B: __nss_endent (in /usr/lib/libc-2.28.so)
==4664== by 0x4DA6EFF: endhostent (in /usr/lib/libc-2.28.so)
==4664==
==4664== 57,344 bytes in 14 blocks are indirectly lost in loss record 8 of 11
==4664== at 0x4848114: malloc (vg_replace_malloc.c:299)
==4664== by 0x4C7CDB7: ogg_stream_init (in /usr/lib/libogg.so.0.8.3)
==4664== by 0x1310B3: ??? (in /usr/bin/icecast)
==4664==
==4664== 114,688 bytes in 14 blocks are indirectly lost in loss record 9 of 11
==4664== at 0x4848114: malloc (vg_replace_malloc.c:299)
==4664== by 0x4C7CDC7: ogg_stream_init (in /usr/lib/libogg.so.0.8.3)
==4664== by 0x1310B3: ??? (in /usr/bin/icecast)
==4664==
==4664== 229,376 bytes in 14 blocks are indirectly lost in loss record 10 of 11
==4664== at 0x4848114: malloc (vg_replace_malloc.c:299)
==4664== by 0x4C7CDA7: ogg_stream_init (in /usr/lib/libogg.so.0.8.3)
==4664== by 0x1310B3: ??? (in /usr/bin/icecast)
==4664==
==4664== 408,128 (6,720 direct, 401,408 indirect) bytes in 14 blocks are definitely lost in loss record 11 of 11
==4664== at 0x484A464: calloc (vg_replace_malloc.c:752)
==4664== by 0x131097: ??? (in /usr/bin/icecast)
==4664==
==4664== LEAK SUMMARY:
==4664== definitely lost: 6,720 bytes in 14 blocks
==4664== indirectly lost: 401,408 bytes in 42 blocks
==4664== possibly lost: 0 bytes in 0 blocks
==4664== still reachable: 10,360 bytes in 28 blocks
==4664== suppressed: 0 bytes in 0 blocks
==4664==
==4664== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==4664== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==4664== could not unlink /tmp/vgdb-pipe-from-vgdb-to-4664-by-root-on-???
==4664== could not unlink /tmp/vgdb-pipe-to-vgdb-from-4664-by-root-on-???
==4664== could not unlink /tmp/vgdb-pipe-shared-mem-vgdb-4664-by-root-on-???
```Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2365Discussion on the handling of portless Host:-headers2020-10-11T15:59:37ZPhilipp SchafftDiscussion on the handling of portless Host:-headersKarl updated Icecast in 64d2fc1faa46cf98b0576521c4975d3ae43ff252 to ignore Host:-headers that do not include a port. This was done due to the fact that winamp and foobar2000 do send invalid Host:-headers. They do not include the port eve...Karl updated Icecast in 64d2fc1faa46cf98b0576521c4975d3ae43ff252 to ignore Host:-headers that do not include a port. This was done due to the fact that winamp and foobar2000 do send invalid Host:-headers. They do not include the port even if non-default ports are used. When this header is used this results in invalid playlists to be generated. (Other (future) uses such as vhosting may also be affected).
foobar2000 seems to have fixed this. This was the result of a quick test with @laama. Thanks to him.
Winamp 5.53 1898 Beta from 2008 as well as Winamp 5.8 as downloaded today are still affected.
The following solution and workarounds come to mind:
* Nullsoft fixes their software. (Judge yourself if this is going to happen.) This is the only solution. It is the only correct way to do this.
* Keep ignoring Host:-headers that do not include a port. This may break legitimate clients.
* Try to match Host:-headers against listen sockets. This may break vhosting.
* Implement a way to list valid vhosts and set default vhosts per listen socket.
* Ignore Host:-headers without a port but implement a per listen socket default vhost setting.
Note that we can not accept/reject Host:-headers without port based on if we listen on a default port socket or not without type="virtual" listen sockets. This will otherwise break all kinds of redirects.
This ticket is mostly for discussion.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2361Remove RAWURI values from URL auth2018-11-27T09:57:57ZPhilipp SchafftRemove RAWURI values from URL authCurrently the URL auth system transmits the RAWURI value if available as "mount"-parameter. This includes query strings. However it does not include POST parameters (therefore is inconsistent).
This should be deprecated and only the res...Currently the URL auth system transmits the RAWURI value if available as "mount"-parameter. This includes query strings. However it does not include POST parameters (therefore is inconsistent).
This should be deprecated and only the resource the user connected to should be included.
It must be discussed if it should transmit the original resource name (before `<resource>` processing) if they differ.
See also: #2360.