Hi there,
2018-06-13 10:28 GMT+02:00 p g :
> hi all,
> so, it's about windows build again.
> i used to say that one of my two radios, the simplier one, is doing fine
> without a memory leak, but after two months of continuous running it
managed
> to crawl past 500MB, although started shy of 40MB.
hi all,
so, it's about windows build again.
i used to say that one of my two radios, the simplier one, is doing fine
without a memory leak, but after two months of continuous running it managed
to crawl past 500MB, although started shy of 40MB.
that is to say memory leak is really present, teln
hi!
will do tonight.
by the way, semi dead telnet issue should be reproducible with any script.
after execution of first command whatever that might be, even 'help', it ceases
to work / respond.
cheers,
p
> On 8 Apr 2018, at 17:35, Romain Beauxis wrote:
>
> Yes please. Even better, if you co
see
> maybe some module invokes that memory growth.
> they share basic structure, but one has multiple input harbors, dynamic
> processing, silence cutting
>
> p
>
> -Original Message----- From: Romain Beauxis
> Date: 2018 m. balandžio 6 d. 19:37
> To: savonet-use
eauxis
Date: 2018 m. balandžio 6 d. 19:37
To: savonet-users
Subject: Re: [Savonet-users] Liquidsoap windows builds are back! / memory
leak
Thanks for your response. I'm still quite puzzled by this issue to be
honest. Memory management is one of the core and solid feature of the OCaml
compiler
't ate all of the memory, but I
> didn't have any live shows through harbor during this time, so can't be
> sure.
>
> just to be precise, i'm running x64 version.
>
> cheers,
> p
>
> -Original Message- From: Romain Beauxis
> Date: 2018 m. kov
Date: 2018 m. kovo 16 d. 17:19
To: savonet-users
Subject: Re: [Savonet-users] Liquidsoap windows builds are back! / memory
leak
Hi again!
The OCaml cross-compiler was recently updated to version 4.06.1 so I've
uploaded a new windows build here:
https://github.com/savonet/liquidsoap/relea
Hi again!
The OCaml cross-compiler was recently updated to version 4.06.1 so I've
uploaded a new windows build here:
https://github.com/savonet/liquidsoap/releases/tag/win32-port
Would you mind trying it to see if the previous memory issues also appear
with this one?
Thanks!
Romain
2018-01-24 1
Hey there,
Thanks for your continuing observations on this. I've been quite busy
lately but I'll go back to it ASAP.
Romain
2018-01-24 9:25 GMT-06:00 p g :
> and here are some more insights on liquidsoap windows (x64 for this
> matter, but should apply to x32 too).
>
> memory leak is not innoce
and here are some more insights on liquidsoap windows (x64 for this matter,
but should apply to x32 too).
memory leak is not innocent, that is, when the ram usage grows it's not
unusual to see the radio playing emergency track instead of playlists, as if
it they were unaccessible. at that poin
happy dog's!
i've been running liquidsoap for a while already and found a bit more about
it:
memory usage grows with time even with 'simple' radio config, but it's not
extreme. after weeks of running it's at 170MB instead of startup's 40.
more 'complicated' radio with few harbors, buffers a
[Savonet-users] Liquidsoap windows builds are back! / memory
leak
Ok thanks. The reason I would like to audit memory usage is that OSes can
have different strategy for allocating memory, including having some memory
reported as used but not actually wired. We never had any memory issues with
t
Ok thanks. The reason I would like to audit memory usage is that OSes can
have different strategy for allocating memory, including having some memory
reported as used but not actually wired. We never had any memory issues
with that part of the code before and it hasn't changed much so I'm tempted
t
some more insight on windows 'memory leak'.
at first i thought it would grow steadily and indefinetly but well... i let
it grow these days and what i'm seeing now is process consuming 2G of RAM.
it's quite an amount compared with more or less steady 40M usage of my
'simpler' radio.
well, at l
Hey!
I can reproduce the crash, alas. Going to investigate it further.
2017-12-20 6:16 GMT-06:00 p g :
> hi, Romain!
>
> it produces .pid (short, with no use i guess) and crashes [ntdll.dll
> error] in a few seconds if i set the environment variable to 1000 and run
> from commandline (files atta
hi, Romain!
it produces .pid (short, with no use i guess) and crashes [ntdll.dll error]
in a few seconds if i set the environment variable to 1000 and run from
commandline (files attached);
if i run it as service with global env variable set, it also crashes, but
with no .pid, and fills in log
Ok, here you go:
https://github.com/savonet/liquidsoap/releases/download/win32-port/liquidsoap-1.3.3-beta4-spacetime-win64.zip
You should start this version this way:
% OCAML_SPACETIME_INTERVAL=1000 liquidsoap.exe <...>
Each run that will give you a file spacetime- where pid is the
process's id.
Ok, thank you. I'm currently building a new liquidsoap binary that will
have memory usage debugging enabled so you should be able to generate a
full report next time you see the issue happen.
Romain
2017-12-19 19:38 GMT-06:00 p g :
> a bit more about win build's memory leak:
>
> it's not predict
a bit more about win build's memory leak:
it's not predictable. one time it might get triggered with some event, other
time under same conditions - not. it might stop growing at some point.
i observed climbing up to 900 Meg and staying there...
on the other hand, my other (simpler config, fewe
okay, some more update on memory leak.
so it played that harbor input [ogg flac] for an hour or so, during that
time grew till 400M ram usage and then switched to some other (lower
priority) source, although streamer seemed to be still feeding proper stream
to harbor. so i restarted the proces
Well noted. I'll have a look asap. Thanks!
2017-12-18 13:43 GMT-06:00 p g :
> hi again,
>
> some days ago i reported memory leak which is triggered by telnet
> connection.
> now i can confirm identical behaviour with external harbour connected.
> functionally it works, broadcast is incoming and p
hi again,
some days ago i reported memory leak which is triggered by telnet
connection.
now i can confirm identical behaviour with external harbour connected.
functionally it works, broadcast is incoming and playing, but liquidsoap.exe
memory usage is steadily growing as i write.
x32 and x64
22 matches
Mail list logo
