similar to: memory leak

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 re all, this patch has not been integrated in Debian yet, hence the Icecast2 package still segfaults after filling up all the memory with its leak. as this is a critical bug, while it seems that the current Debian mantainer for the icecast2 package has abandoned its duty, i'm kindly asking the attention of debian developers included

I have to register asterisk/sip with a sipproxy that does not support authentication, I do not know how to tell Asterisk not to send authentication request? # sip.conf [general] insecure=very permit=207.148.115.10/255.255.255.0 [myproxy] type=friend host=217.118.115.10 context=from-sip # Logging: <--- Reliably Transmitting (NAT) to 207.148.115.10:5060 ---> SIP/2.0 407 Proxy

Hi! Seems we're facing some memory leak here. This is vanilla 2.6.19-rc6 on a x86_64 box, 4GB RAM. A simple `ls -Rn' on a filesystem with lots of files makes the box leak so much RAM that the OOM killer starts to kick in. With slab alloc debugging turned on, we see this: # mount; ls -Rn; wait some seconds; Ctrl-C [root@lnxp-1038:/backend1]$ cat /proc/slab_allocators | egrep

On 09/12/2009 16:59, Romain Beauxis wrote: > Hi ! > > Le mardi 8 d?cembre 2009 19:59:23, Karl Heyes a ?crit : >>> But since you asked, attached are the missing frees for icecast2_2.3.2-4 >>> in a totally untested drive-by-patching manner. Like I said the -kh17 I >>> also happened to have did not have this specific code at all and the >>>

I'm having trouble tracking down why it leaks, but below is an example program which shows--using valgrind--that vorbis_info_clear() leaks memory if called before vorbis_dsp_clear(), but not if called after vorbis_dsp_clear(). Just compile and run under valgrind, using the -l switch to the example program to trigger a leak. Tested under OS X 10.7 and Ubuntu 12.04. This may be by design, or

Hi All, Not sure exactly a memory leak or not. I was porting my nagios from Redhat 7.3 to CentOS 5.4 and I observed the memory usage was gradually increasing on the new centos box. When I ran all my perl plugins with Valgrind -3.2.1, all the plugins complained about a memory leak. Not sure if it's a leak or if its fault with valgrind way of evaluating things. I have attached

On 11/08/2014 05:41 AM, Ian Campbell wrote: > Please can you try running xl under valgrind, something similar to what > I described earlier should work. I guess it didn't find much.. # valgrind --leak-check=full xl cr -F /etc/xen/auto/asterisk_deb80.cfg ==6736== Memcheck, a memory error detector ==6736== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==6736== Using

From: Jie Liu <jeff.liu at oracle.com> Subject: ocfs2: fix a memory leak in __ocfs2_move_extents() The ocfs2 path is not properly freed which leads to a memory leak at __ocfs2_move_extents(). This patch stops the leaks of the ocfs2_path structure. Signed-off-by: Jie Liu <jeff.liu at oracle.com> Reviewed-by: Younger Liu <younger.liu at huawei.com> Cc: Joel Becker <jlbec at

Hi, in part of my code I need to optimize a function from within Rcpp (I followed the 2nd answer here https://stackoverflow.com/questions/48348079/applying-the-optim-function-in-r-in-c-with-rcpp). However, I found that the function leaks memory (very little, but it compounds if it's a part of repeatedly running simulation). I created a minimal reproducible example, but I have no idea where

Hello everyone, we''ve recently discovered a memory leak in the PerFieldAnalyzer. If you use the PerFieldAnalyzer (which you acutally should), you should switch to a pure ruby version of that analyzer. The C version of the Analyzer is consuming memory on every analyzing request. You can find an example script to verify the leak[1]. Furthermore we''ve added a workaround, building

https://bugzilla.mindrot.org/show_bug.cgi?id=3718 Bug ID: 3718 Summary: Small memory leak (+patch) in process_server_config_line_depth Product: Portable OpenSSH Version: -current Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: sshd

reopen 767295 thanks The 4.4.1-4 release only included one related fix there are actually two more: commit 379b351889a8f02abe30a06e2ce9ba8b381b91ab Author: Ian Campbell <ian.campbell at citrix.com> Date: Thu Nov 6 13:00:31 2014 +0000 tools: libxl: do not leak diskpath during local disk attach

https://bugzilla.samba.org/show_bug.cgi?id=8475 Summary: memory leak around free_xattr() and rsync_xal_free(), with -aX, 200 bytes per file and per directory Product: rsync Version: 3.0.9 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core

Hey all, I believe there is a memory leak when using Win2000 + SQL Server + Apache2 + scgi + rails 1.1. My apps so far have been pretty ''low impact'' and i did not notice it before, but the memory footprint of ruby.exe is growing larger. After 6 queries that fetch ~2,000 rows each, ruby.exe has grown to 41 megs (originally around 20). The memory leak is also present in webrick,

Hi Reid, I guess it's not so much a memory leak, as unexpected behaviour, resulting in excessive memory use. I also call the following after EE->runFunction, which seems to clean up pretty nicely. EE->freeMachineCodeForFunction(stub); // Delete functions and IR. stub->deleteBody(); stub->eraseFromParent(); Rob. -----Original Message----- From: reid.kleckner at

Asterisk Project Security Advisory - AST-2017-011 Product Asterisk Summary Memory leak in pjsip session resource Nature of Advisory Memory leak Susceptibility Remote Sessions Severity Minor

I was looking more closely on the source for Darkice. I found the code for calulating the buffersize somewhat strange. Your is snapshot taken from the init function in CastSink.cpp : int bufferSize = bitRate ? (bitRate * 1024 / 8) * bufferDuration : (128 * 1024 / 8) * bufferDuration; bufferedSink = socket ? new BufferedSink( socket,

On Mon, 9 Jan 2012, Doc Nasty wrote: > To: icecast at xiph.org > From: Doc Nasty <doc at krushradio.com> > Subject: Re: [Icecast] ices2 memory leak on Debian/ARM (The Darkener) > > Justin, > > I'm not a linux guy, or a that well versed on ICES, but, I went thru the > code (stream.c) and just kinda nosed around the broadcast part. When we > look at distros

ARM, default install on an Ionics Stratus plug computer - http://www.ionicsplug.com/stratus.html ) - running Current Debian Stable. - Jordan On 01/10/2012 03:13 PM, Christian Eichert [K9] wrote: > Can you describe your architecture? > -- > Christian Eichert > > ------------------------------------------------------------------------ > *Von:* TheDarkener <thedarkener at

On Fri, Nov 11, 2016 at 12:46 PM, Gergely Dar?czi <daroczig at rapporter.net> wrote: [...] >> I've changed the above to *print* the gc() result every 1000th >> iteration, and after 100'000 iterations, there is still no >> memory increase from the point of view of R itself. Yes, R does not know about it, it does not manage this memory (any more), but the R process