Hi Paulo, Sorry for the delay. Honestly, it is rather difficult to reproduce the problem here, however the issue sounds rather critical, so we've just done few modifications in pasound.c, please see ticket #701 (http://trac.pjsip.org/repos/ticket/701). Thanks for the report (and the detail!). Regards, nanang On Sat, Jan 17, 2009 at 3:34 AM, Paulo Sousa <psousa at wit-software.com> wrote: > Hello Benny, > > We are maintaining an application that is based on a licensed pjsip stack > with support during 2008 (I am retransmitting this email, as I had no > reply). We are currently using rel-0.9.0, but this issue can also be > observed in the trunk. > > We ran into a intermittent problem with memory corruption on the Windows > version of the application, that we traced to sound stream handling in > "pasound.c". > > For each call, the application is calling "pjmedia_snd_port_create()" at the > start of the call and "pjmedia_snd_port_destroy()" at the end of the call. > After the second call, the application got corrupted heap sections. > > We noticed that after the second call, the thread that is receiving sound > frames by PortAudio through "PaPlayerCallback()" had an invalid structure in > it's TLS when calling pj_thread_this(). On the second call, the thread was > not being registered, so the initial thread register was referencing the > memory pool of the first call. > > > Apparently, this issue had already been addressed, but it was changed > because of a MacOS behavior: > > // Sometime the thread, where this callback called from, is changed > // (e.g: in MacOS this happens when plugging/unplugging headphone) > // if (stream->play_thread_initialized == 0) { > if (!pj_thread_is_registered()) { > status = pj_thread_register("portaudio", stream->play_thread_desc, > &stream->play_thread); > //stream->play_thread_initialized = 1; > PJ_LOG(5,(THIS_FILE, "Player thread started")); > } > > > The problem can be confirmed by simply placing a PJ_CHECK_STACK() at the end > of the following block: > > // Sometime the thread, where this callback called from, is changed > // (e.g: in MacOS this happens when plugging/unplugging headphone) > // if (stream->play_thread_initialized == 0) { > if (!pj_thread_is_registered()) { > status = pj_thread_register("portaudio", stream->play_thread_desc, > &stream->play_thread); > //stream->play_thread_initialized = 1; > PJ_LOG(5,(THIS_FILE, "Player thread started")); > } > PJ_CHECK_STACK(); > > > To resolve this issue, we reverted back to the original code, by > uncommenting the previous implementation: > > // Sometime the thread, where this callback called from, is changed > // (e.g: in MacOS this happens when plugging/unplugging headphone) > if (stream->play_thread_initialized == 0) { > // if (!pj_thread_is_registered()) { > status = pj_thread_register("portaudio", stream->play_thread_desc, > &stream->play_thread); > stream->play_thread_initialized = 1; > PJ_LOG(5,(THIS_FILE, "Player thread started")); > } > PJ_CHECK_STACK(); > > > Unfortunately, from the comment, this will not work under MacOS, as it may > deliver frames from different threads. > > Do you agree with the problem we reported, and if so, can you offer a > solution that will work both with MacOS and Win32? > > Best Regards, > Paulo > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > >
