similar to: Issue with memory deallocation/fragmentation on systems which use glibc

On Sat, 12 Aug 2017, Dmitriy Selivanov wrote: > Strange because in my all my experiments calling malloc.trim always helped > - memory reported by top decreased to the level it supposed to be. Do you > have in mind case when calling malloc.trim won't do anything? Also > shouldn't MALLOC_TRIM_THRESHOLD_ env variable has impact on malloc.trim > calls? At the moment seems any

Very interesting information about switching glibc malloc to jemalloc. So I see action plan as following: 1. set up some benchmark (need to think about design) 2. Run it on ubuntu machine with default glibc malloc 3. Run it with malloc_trim passed with reg.finalizer() 4. Run it with jemalloc 5. Review results and if they will look better than with glibc malloc - possibly

Strange because in my all my experiments calling malloc.trim always helped - memory reported by top decreased to the level it supposed to be. Do you have in mind case when calling malloc.trim won't do anything? Also shouldn't MALLOC_TRIM_THRESHOLD_ env variable has impact on malloc.trim calls? At the moment seems any value is ignored... 12 ???. 2017 ?. 6:09 ?? ???????????? "Simon

On 12 August 2017 at 15:10, luke-tierney at uiowa.edu wrote: | As the Python posts poitns out, it is possible to use alternate malloc | implementations, either rebuilding R to use them or using LD_PRELOAD. | On Ubuntu for example, you can have R use jemalloc with | | sudo apt-get install libjemalloc1 | env LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1 R | | This does not seem to hold

Hi mailing list and R-core. Could someone from R-core please help me to create account in bugzilla? I would like to submit issue related to gc() to wishlist. Related context is here - https://stat.ethz.ch/pipermail/r-devel/2017-July/074715.html -- Regards Dmitriy Selivanov [[alternative HTML version deleted]]

The problem is that the drop is only applied (or not) after the subsetting, so what R does is: - Getting the subset, which means a 1 x 1 matrix. - Only then It either returns that as is (when drop=FALSE), or removes ALL dimensions of extent 1, regardless of whether these are rows or columns (or higher dimensions). And it can't keep any names, because what name should be returned? The name

>>>>> Dmitriy Selivanov <selivanov.dmitriy at gmail.com> >>>>> on Fri, 11 Aug 2017 17:33:31 +0400 writes: > Hi mailing list and R-core. Could someone from R-core please help me to > create account in bugzilla? I would like to submit issue related to gc() to > wishlist. I will create one. Your previous e-mails left me pretty clueless

2017-08-11 16:00 GMT+02:00 Martin Maechler <maechler at stat.math.ethz.ch>: >>>>>> Dmitriy Selivanov <selivanov.dmitriy at gmail.com> >>>>>> on Fri, 11 Aug 2017 17:33:31 +0400 writes: > > > Hi mailing list and R-core. Could someone from R-core please help me to > > create account in bugzilla? I would like to submit issue

Hi Rui. Thanks for answer, I'm aware of drop = FALSE option. Unfortunately it doesn't resolve the issue - I'm expecting to get a vector, not a matrix . ??, 21 ????. 2018 ?. ? 20:54, Rui Barradas <ruipbarradas at sapo.pt>: > Hello, > > Use drop = FALSE. > > a[1, , drop = FALSE] > # col1 > #row1 1 > > > Hope this helps, > > Rui Barradas

Dmitriy Selivanov (selivanov.dmitriy at gmail.com) wrote: > Consider following example: > > a = matrix(1:2, nrow = 2, dimnames = list(c("row1", "row2"), c("col1"))) > a[1, ] > # 1 > > It returns *unnamed* vector `1` where I would expect named vector. In fact > it returns named vector when number of columns is > 1. > Same issue applicable

> On Aug 11, 2017, at 12:57 PM, I?aki ?car <i.ucar86 at gmail.com> wrote: > > 2017-08-11 16:00 GMT+02:00 Martin Maechler <maechler at stat.math.ethz.ch>: >>>>>>> Dmitriy Selivanov <selivanov.dmitriy at gmail.com> >>>>>>> on Fri, 11 Aug 2017 17:33:31 +0400 writes: >> >>> Hi mailing list and R-core. Could

Hello here. I'm struggling to understand R's subsetting behavior in couple of edge cases - subsetting row in a single column matrix and subsetting column in a single row matrix. I've read R's docs several times and haven't found answer. Consider following example: a = matrix(1:2, nrow = 2, dimnames = list(c("row1", "row2"), c("col1"))) a[1, ] # 1

Hi, I've being using nut 2.2.2 (Debian Lenny) via megatec_usb driver for IPPON Back UPS 600. Then I upgraded to nut 2.4.3 (Debian Squeeze) with broken megatec_usb. I moved to blazer_usb, it connected IPPON. [myups] driver = blazer_usb port = /dev/usb/hiddev0 desc = "Local UPS" #from megatec.c: batteries[] = {{ 12.0, 9.0, 16.0, 9.7, 13.7, 0.0 },

I repeatedly get a popup when running an old Windows 3.1 game on Ubuntu, Wine 0.9.59. It reads ... Memory BUG Deallocation of a locked memory block I can usually continue OK, but it's very annoying. Is there anything I can do about it? Thanks.

Hi, So 9316 works and 9320 doesn't? How about latest SVN. I just ran everything in valgrind and saw no error at all. Can you give more info on how to reproduce (with speexenc)? Jean-Marc Le mercredi 22 juin 2005 ? 21:19 -0300, Dario Andrade a ?crit : > > > When updating the speex sources from svn tree, I found that the > following revision has corrupted the deallocation

This issue certainly affects unstable, 4.2 and 4.1, and probably affects previous releases as well. It has been tested by using 40 VMs with 8 devices passed through to each, in a reboot loop. Before the fix, the host would reliably crash before the end of the first reboot cycle, whereas with the fix, the VMs are on their 20th reboot cycle with no issue. -- Andrew Cooper - Dom0 Kernel Engineer,

On Mon, 3 Dec 2007, Benjamin Smedberg wrote: > I've been reading the headers and > http://llvm.org/releases/2.1/docs/ProgrammersManual.html and I'm still > confused about a pretty fundamental point... who is expected to clean up > various objects when we're finished with them, and when? Ok, different objects have different life times. The important ones are: (most)

On Mon, 2007-12-03 at 18:56 -0800, Chris Lattner wrote: > Other IR objects (like instructions) have very simple ownership. An > instruction is owned by its basic block, a bb is owned by the function, a > function is owned by thet module. If an instruction is initially allocated with its Instruction *insertAtEnd parameter defaulted to null, and then later appended to a BasicBlock,

I noticed that in the narrow band and wide band destroy functions only the main pointer is being freed. I think that it should be: void nb_decoder_destroy(void *state) { DecState *st; st=(DecState*)state; speex_free (st->inBuf); speex_free (st->excBuf); speex_free (st->innov); speex_free (st->interp_qlpc); speex_free (st->qlsp); speex_free

> So 9316 works and 9320 doesn't? How about latest SVN. I just ran > everything in valgrind and saw no error at all. Can you give more info > on how to reproduce (with speexenc)? > > Jean-Marc > I went to check my code and it turned out to be a fault in the speex_encoder_destroy being used to destroy a decoder state. It seems that the new revision thriggered this error.