Would it be possible to include a re-export of the malloc, calloc, realloc, and free being used by opus file's implementation of OpusTags handling? This might seem redundant or ridiculous but I'm having difficulty getting the right versions that my compiler allows that's compatible with libopusfile. In the debugger I can see that the memory location that my malloc is returning is different from what libopusfile is returning in tags handlers. So of course when I call opus_tags_clear or any other tags modification routine on an OpusTags struct with contents created by my call to malloc it throws an exception. At the moment I've worked around it by loading and using MSVCRT.dll's malloc, calloc, realloc, and free but I have a feeling it's the wrong way to go about that. I found it in the call stack trace when my debugger caught an application defined exception on the call to opus_tags_clear. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20130824/8e60c7aa/attachment.htm
alpha thinktink wrote:> is returning in tags handlers. So of course when I call opus_tags_clear > or any other tags modification routine on an OpusTags struct with > contents created by my call to malloc it throws an exception.Yes, this doesn't work in Windows (it works everywhere else). You can't use malloc/free across module boundaries unless both modules are linked to the same DLL version of libc (static linking to libc also doesn't work).> At the moment I've worked around it by loading and using MSVCRT.dll's > malloc, calloc, realloc, and free but I have a feeling it's the wrong > way to go about that. I found it in the call stack trace when my > debugger caught an application defined exception on the call to > opus_tags_clear.Well, the first question I would ask is, why are you malloc'ing your own memory for an OpusTags structure? Is there some missing API that we could provide that would just avoid the problem?
alpha thinktink wrote:> On Sat, Aug 24, 2013 at 7:56 PM, Timothy B. Terriberry > <tterribe at xiph.org <mailto:tterribe at xiph.org>> wrote: > > alpha thinktink wrote: > > is returning in tags handlers. So of course when I call > opus_tags_clear > > or any other tags modification routine on an OpusTags struct with > > contents created by my call to malloc it throws an exception. > > Yes, this doesn't work in Windows (it works everywhere else). You can't > use malloc/free across module boundaries unless both modules are linked > to the same DLL version of libc (static linking to libc also doesn't > work). > > > Kinda figured as much but its very good to have a confirm. > > > At the moment I've worked around it by loading and using MSVCRT.dll's > > malloc, calloc, realloc, and free but I have a feeling it's the wrong > > way to go about that. I found it in the call stack trace when my > > debugger caught an application defined exception on the call to > > opus_tags_clear. > > Well, the first question I would ask is, why are you malloc'ing your own > memory for an OpusTags structure? Is there some missing API that we > could provide that would just avoid the problem? > _______________________________________________ > > > I am mallocing my own memory for tags because I'm working in an > extremely multi-threaded environment where if I'm not careful with what > and how I CRIT_SECT shared data I can end up dead-locking, therefore, > duplicating the OpusTags data was the safest (and fastest) way to share > data amongst more than several threads. The only other way I can think > of to resolve this issue is to provide a tags duplication function: ie > opus_tags_copy(OpusTags *_dst,const OpusTags *src) and other duplication > functions for other structures as well (for the sake of completeness.)Added in https://git.xiph.org/?p=opusfile.git;h=e96c5aa859f8;a=commitdiff I'm holding off on adding copy routines for the other structures with internal allocations for now, since they are generally not mutable, and the application has better control over the lifetime. But let me know if you wind up needing one.
alpha thinktink wrote:> Thanks. > > At the moment I'm not sharing any headers stuff as that is being purely > internally handled by the playback thread (no need to share it across > threads) and I've already implemented handlers for album art so, at the > moment, I don't predict I'll need a copy function for anything else. > Others might though for the new album art handler but other than me, no.Well, that at least has a simple (if slightly inefficient) solution: call opus_picture_tag_parse() again.