Hi Paulo & Nanang, i assume you are using DirectX and that your application closes the sound device when the call tears down. In order to avoid a memory corruption you MUST unregister the sound device thread before shutting it down. This can be done in the Pa_TimerCallback function. This patch did solve that problem for us! Cheers, Alain Nanang Izzuddin wrote: > 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 >> >> > > _______________________________________________ > 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 > -- "" (o)(o) ___o00o__(__)__o00o_____ 1024D/A9F85A52 2000-01-18 Dipl.-Ing. Alain Totouom <totouom at gmx.de> PGP Fingerprint DA18 0DF2 FBD2 5F67 0656 452D E3A2 7531 A9F8 5A52 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pjsip-2426-unregister_thread.patch URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090121/0c086a24/attachment-0001.patch>
