similar to: Slight memory leak or bad documentation

On Sun, Jun 12, 2011 at 12:30 AM, <flac-dev-request at xiph.org> wrote: > Send Flac-dev mailing list submissions to > flac-dev at xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xiph.org/mailman/listinfo/flac-dev > or, via email, send a message with subject or body 'help' to > flac-dev-request at

> I've recently run it through valgrind, and I'm seeing memory leaks like the > following: > > 12 bytes in 1 blocks are definitely lost in loss record 1 of 5 > at 0x402377E: operator new(unsigned) (vg_replace_malloc.c:224) > by 0x41448A8: FLAC::Metadata::local::construct_block(FLAC__StreamMetadata*) > (in /usr/lib/libFLAC++.so.6.2.0) ? by 0x41455D7: >

Hi all, I'm the author of flactag, a utility for tagging whole-album FLAC files with embedded CUE sheets using data from the MusicBrainz servers. I've recently run it through valgrind, and I'm seeing memory leaks like the following: 12 bytes in 1 blocks are definitely lost in loss record 1 of 5 at 0x402377E: operator new(unsigned) (vg_replace_malloc.c:224) by 0x41448A8:

Hi all! I have a problem to get _all_ images from flac file. I have flac file with 3 images inside ( FLAC__METADATA_TYPE_PICTURE ) How to get _all_ images with bool FLAC::Metadata::get_picture() func? This function is wrapper FLAC__bool FLAC__metadata_get_picture(). flac-1.2.1/src/libFLAC/metadata_iterators.c: ... 285 FLAC_API FLAC__bool FLAC__metadata_get_picture(const char *filename,

Hey! So, I'm clearly doing something wrong, because I've written a program to view and modify the comment tags in a FLAC file, which appears to be embedded an Ogg stream. This particular file also has ID3 headers at the beginning, but I was planning on ignoring those and fixing them up using some ID3 code later on ... Now, to read the comments is quite simple:

V1->V2: -Changed dio_end_io to EXPORT_SYMBOL_GPL -Removed the own_submit blockdev dio helper -Removed the boundary change V2->V3 -Made it so we keep track of what the current logical offset in the file we have a BIO setup for so we can pass it into the submit_io hook. Because BTRFS can do RAID and such, we need our own submit hook so we can setup the bio''s in the correct fashion,

metaflac --import-vc-from ... used on flac file without vorbis comment destroys the file. This patch fix it. -- Miroslav Lichvar -------------- next part -------------- --- src/metaflac/main.c.orig 2002-09-28 14:45:49.000000000 +0200 +++ src/metaflac/main.c 2002-10-06 23:36:26.000000000 +0200 @@ -1754,20 +1754,24 @@ found_vc_block = true; } while(!found_vc_block &&

On Sun 18-06-23 23:32:47, Bean Huo wrote: > From: Bean Huo <beanhuo at micron.com> > > block_commit_write() always returns 0, this patch changes it to > return void. > > Signed-off-by: Bean Huo <beanhuo at micron.com> Looks good to me but you'll need to reorder this patch at the end of the patch series to avoid breaking compilation in the middle of the series.

Hi List, I recently was assigned a task to port FLAC Encoder to our embedded platform. Thanks to OO-like design of the libFLAC and throught documentation, that porting went like a charm. I had some problems with chmod/chown like routines while porting but I was able to safely remove that piece of code without any trouble. I have observed that the my application FLAC Encoder failes in

llvm code generator lowers both integer and pointer types into ixx(say, i16, i32, i64, ...). This make senses for some optimizations. However, integer registers and pointer registers is expilicitly distinguished from each other for some architectures, like TriCore, Blackfin, and our lab prototype dsp, which accelerates address computation and memory access. I have already read this mail thread:

We also have this problem, and have added iPTR types to the back end. Our pointers are actually fat pointers, so this also requires tweaking some optimisations (for example, things like to turn GEPs with 64-bit offsets into pointer-sized offsets, but our pointers are larger than any integer type that we support...). Most of the changes are a bit ugly, and I'm loath to upstream them without

The patch titled Subject: fs: convert block_commit_write to return void has been added to the -mm mm-unstable branch. Its filename is fs-convert-block_commit_write-to-return-void.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/fs-convert-block_commit_write-to-return-void.patch This patch will later appear in the

I'm one of the developers of Notmuch, an email client that makes extensive use of Xapian. For some time, full multi-version concurrency control (MVCC) has been on our wish list. Olly mentioned that brass now uses free lists---a key step toward full MVCC---and I offered to pitch in on putting the other pieces into place. Before I wade too deep into this, I wanted to propose my plan. Full

Hi all, recently I tried to add cover art to flac files and have dfficulties in doing so. FLAC__Metadata_Chain *chain = FLAC__metadata_chain_new(); if(0 == chain) return; if(!FLAC__metadata_chain_read(chain, filename)) return; FLAC__StreamMetadata *picture = FLAC__metadata_object_new(FLAC__METADATA_TYPE_PICTURE); FLAC__Metadata_Iterator *iterator = FLAC__metadata_iterator_new(); if(0 ==

--- Joshua Kwan <joshk@triplehelix.org> wrote: > Well, I'm quite frankly stumped. I'm writing a program that recurses > into directories and reads (among others) FLAC files and should be > able > to read the vorbis comments ARTIST and TITLE from the file. > > A while back, I was popen()ing to metaflac, because I didn't want to > mess with libFLAC. But now,

David, thanks for your immediate response. Since iPTR is a reserved type for tablegen internal use, can you make a further explanation? On the other hand, it can be simply treated as a register class assignment problem during register allocation. Assume both pointer and integet have a 32 bit width. backend handles it just as to i32. When it performs register allocation, it can retrieve from

Hi, In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers. This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types. We've added a flag that can be set on a per-backend basis to turn this off. Our problem is perhaps a bit different form yours,

The patch titled Subject: fs/buffer: clean up block_commit_write has been added to the -mm mm-unstable branch. Its filename is fs-buffer-clean-up-block_commit_write.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/fs-buffer-clean-up-block_commit_write.patch This patch will later appear in the mm-unstable branch

Hi, this is about an issue newer kernels show, bysplitting direct I/O requests into 4k pieces to directly merge them in the Block Device Layer afterwards. If anyone is interested in own tests just use a simple command like dd if=/mnt/test/test-dd1 of=/dev/null iflag=direct bs=64k count=1 in combination with blktrace. The following patch is more a proposal for discussion than a solution, well

--- On Tue, 5/8/12, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Honestly, I really doubt this is a bug in valgrind :-). How > were you testing > this? Well, I've read that there have been bugs in valgrind, were SSE optimized versions of strlen() do guaranteed safe overreads of memory, but valgrind wasn't aware the overreads were safe. Anyway, it seems easy to