Re: [Audacity-devel] reproducable crash

[Dominic M. <do...@mi...>]

wxTimers are not threads.  wxWindows does offer threading support,
but wxTimers are much more lightweight - timer handlers get called
during the main event loop (or during wxYield() calls).

However, note that even though Audacity doesn't actually use any
threads in its cross-platform code, the new OSS driver I wrote
does use a separate thread.  (Apparently that's the only way
to do real-time audio that works with all audio drivers since
some drivers ONLY support blocking mode.)

It's likely the problem is with the mutexes.  I'll try to reproduce
the crash on my system.

- Dominic


Augustus Saunders wrote:

> 
> 
> Sean Neakums wrote:
> 
>> begin  Joshua Haberman quotation:
>>
>>> Shoot, is the list down again? I haven't gotten the list's copy of
>>> your reply, nor a message I sent late last night. Urgh.
>>>
>>> * Dominic Mazzoni (do...@mi...) wrote:
>>>
>>>> I'm pretty sure the bug is actually in the new OSS Audio I/O code I
>>>> wrote.  I can't reproduce it, but check out snd/audiooss.c, that's
>>>> the most likely place for the error.  AudioIO.cpp hasn't changed in
>>>> months, and it generally works fine, but I just rewrote
>>>> snd/audiooss.c, so that's where I'd look first.
>>>>
>>> I don't understand why the backtrace would show the crash where it
>>> does though. Why should 'new' ever crash? What would I be looking
>>> for in audiooss.c that would cause this kind of crash?
>>>
>>
>> new (and malloc) could crash if the headers it uses to keep track of
>> allocations are overwritten somehow, for example, by writing too much
>> data into a buffer.  It all depends on how new is implemented.
>>
> Just to clarify a little bit, generally, when you allocate a block of 
> memory, say 1024 bytes,
> 
> char *ptr = new char[1024];
> 
> or something like that, you don't get just 1024 bytes of memory.  There 
> is some overhead that the operating system introduces to keep track of 
> where available memory is.  A lot of times, each block of memory 
> allocated is prepended with information about where to find the next 
> block of allocated memory.  Then, when you call delete[] ptr; the OS can 
> figure out how much memory is actually being freed (that's why you don't 
> have to say delete[1024] ptr; the OS already knows).  So, if you call 
> delete (or free, which delete eventually calls usually) on a bad pointer 
> (say (ptr + 17)), the OS can get really confused.  In that case, you'll 
> probably corrupt memory and likely crash.  So what about new?  I'm a 
> little sketchy on the details, but new walks through the list of headers 
> to figure out where to allocate the memory.  If some of the headers have 
> been corrupted (by a different operation), then  new (or malloc) will 
> wind up dereferencing illegal memory.  But Sean's right, it depends on 
> how malloc is implemented--I doubt in this case it really depends on 
> *new*, actually, as shown by your stacktrace.  If you want (or need), I 
> can explain what new does on top of mallocing.  The take home message 
> here is that crashing in malloc or free (or new or delete) generally 
> means memory corruption.  Based on the fact that you said that it 
> happens after about 2:20 of recording, that's likely your culprit. 
> You're overwriting some buffer when you get that big, or maybe some 
> operation is triggered at that point that overwrites memory.  Also, I 
> notice that this is happening inside an OnTimer callback.   If that's 
> implemented with a thread of some kind, then you have to think about 
> whether or not malloc and free are threadsafe.  ie, if you get context 
> switched out in the middle of a malloc, and then the next thread starts 
> a malloc, is that safe?  Dominic, do you know if the wxWindows timers 
> are threads on Linux?  I know SDL's are.  Since Linux has generally been 
> process based, I don't know how much the libraries are thread safe. 
> Well, good luck in tracking this down.  These kinds of bugs can be a 
> real PITA.  Later-
> 
> Augustus
> 
> 
> _______________________________________________
> Audacity-devel mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel