Hi Pedro, On 11/07/2008, Pedro Gon?alves <pedro.pandre at gmail.com> wrote: > Nanang Izzuddin wrote: > > Hi Pedro, > > > > Looking into this stack trace: > > > > MyApp.exe!pj_bzero(void * dst=0xfeeefeee, unsigned int > > size=1600) Line 601 + 0xf bytes C > > MyApp.exe!get_frame(pjmedia_port * this_port=0x03713d20, > > pjmedia_frame * frame=0x0712f784) Line 1720 + 0x16 bytes C > > > > The location seems to be in get_frame() of conference.c, so the 'dst' > > of pj_bzero (whose value==0xfeeefeee) should be 'conf_port->mix_buf'. > > Since accessing conf_port in conference bridge is always guarded by > > mutex, the reasons of conf_port->mix_buf having invalid value > > (0xfeeefeee) are: > > - early release of pool. e.g: pool that is used for calling > > pjmedia_conf_add_port, this pool is used for allocating > > conf_port->mix_buf. > Sorry, I didn't understand this 100%: are you saying that the pool used > in *pjmedia_conf_add_port* can't be the same for allocating > conf_port->mix_buf? No, sorry, let me rephrase this... I was trying to say that the pool used for allocating conf_port->mix_buf is the pjmedia_conf_add_port's pool, so please make sure this pool is not released before the conf_port removed from conference bridge. > I don't know where conf_port->mix_buf is allocated, but I am using > pjsip_inv_session's pool in *pjmedia_conf_add_port*. It should be safe *as long as* the conf_port removed immediately when call get disconnected (before the pjsip_inv_session's pool released). > Where can I see which pool is being used to allocate conf_port->mix_buf? It is pjmedia_conf_add_port's pool, don't need to bother with this. > Which pool should I use? > To check whether the problem is caused by premature pool release, try to use application life time pool and see if the problem still occurs. > > - there is buffer overrun somewhere in your app. > I am new no C/C++, and so I'm no expert in buffer overruns... Do you > have any suggestion on how to detect a buffer overrun and how to prevent it? I think it is difficult to detect until a problem occured, like now :) I'm no expert either, uncle google may have a better answer about buffer overrun. > Is this somehow related to the "Master/sound Underflow, buf_cnt=252, > will generate 1 frame" lines that appear in the log? I don't think so, that seems to be different problem :) Regards, nanang
