Can you check if this is still a problem with 1.8.1?

Which test are you running, and on which file? Can you share the file? Does it always happen?

Following is the test  and the stream file attached.
gst-validate-launcher -M /mnt/gst-validate --generate-media-info -t  validate.file.media_check.vorbis_vp8_1_webm

[1 / 1] Launching: validate.file.media_check.vorbis_vp8_1_webm
    Command: 'GST_GL_XINITTHREADS=1 DISPLAY=:0 gst-validate-media-check-1.0  file:///mnt/gst-validate/gst-integration-testsuites/medias/defaults/webm/vorbis_vp8.1.webm --expected-results "/mnt/gst-validate/gst-integration-testsuites/medias/defaults/webm/vorbis_vp8.1.webm.media_info"'
    Logs:
         - /mnt/gst-validate/logs/validate/file/media_check/vorbis_vp8_1_webm
         - /mnt/gst-validate/logs/validate/file/media_check/vorbis_vp8_1_webm.validate.logs
[1 / 1] validate.file.media_check.vorbis_vp8_1_webm: Failed (Application returned 1 (issues: No criticals))

 
I am runnig an  embedded  system. we use different video sink plugin and audio decoder and sink plugin we write. I am not sure this is caused by the plugin we write. I still hope you guy can reproduce it and help to fix.

If not ,could any one tell me how to quickly and accurately locate and fix the problem?

Created attachment 329629 [details]
stream file to reproduce

I would expect this to be related to your platform or the other elements you are using. It seems to work fine here with 1.8.2 and GIT master. please in the future also file only a single bug, it seems to be all the same problem.


For locating this, somewhere in the code the reference counting is apparently done wrong. Most likely related to a GstBuffer that is stored in caps, or it's just memory corruption elsewhere. Best would be to run in valgrind with --track-origins=yes to see what goes wrong and where the memory is from.

Created attachment 329669 [details]
valgrind log

Seems to be related to buffers/memory stored inside the caps, the streamheaders. Please check if your custom elements downstream of the demuxer are handling reference counts of buffers and also the streamheaders inside the caps correctly. As this doesn't happen here, it's probably related to what your custom elements are doing.

from the log ， I still can not locate the problem. I also expect this  to be related to my plugin, but I see nothing related to my plugin from the log. Following may be the related codes. Could you help me to check it? especially the buffer related? 
====================part 1============== 
if (gst_structure_has_field(structure, "streamheader")) {
		 headers = gst_structure_get_value (structure, "streamheader");
        if (headers == NULL || !GST_VALUE_HOLDS_ARRAY (headers)) {
            GST_WARNING ( "no 'streamheader' field in input caps,\n");
            return FALSE;
        }
        num = gst_value_array_get_size (headers);
        GST_WARNING ( "num=%d\n",num);	
        for (i = 0; i < num; ++i) {
            const GValue *header_val;
            GstBuffer *header_buf;

            header_val = gst_value_array_get_value (headers, i);
            if (header_val == NULL || !GST_VALUE_HOLDS_BUFFER (header_val))
            return FALSE;
	   if(i==0){
	      info->configdata =                    gst_buffer_make_writable(gst_value_get_buffer(header_val));
		          if(pcodec->audio_type == AFORMAT_VORBIS)
		   	      pcodec->audio_info.extradata[1] = gst_buffer_get_size (info->configdata );
	          } else {
	   	       header_buf = g_value_dup_boxed (header_val);
		         if(pcodec->audio_type ==AFORMAT_VORBIS && i==1)
		   	     pcodec->audio_info.extradata[2] = gst_buffer_get_size (header_buf);
                GST_WARNING ("pushing header buffer of %" G_GSIZE_FORMAT " bytes "
              " into adapter", gst_buffer_get_size (header_buf));
		         if(header_buf)
	             gst_buffer_copy_into(info->configdata,header_buf,GST_BUFFER_COPY_MEMORY,0,-1);	     
		       }
	      } 
    }


=================part2========================================
gint vorbis_writeheader(AmlStreamInfo* info, codec_para_t *pcodec)
{
	GstMapInfo map;
    if(info->configdata){
    	gst_buffer_map(info->configdata, &map, GST_MAP_READ);
        pcodec->audio_info.extradata_size = map.size;
	   GST_WARNING("size=%d\n",pcodec->audio_info.extradata_size);
        if (pcodec->audio_info.extradata_size > 0) {
            if (pcodec->audio_info.extradata_size >  AUDIO_EXTRA_DATA_SIZE) {
                GST_WARNING("[%s:%d],extra data size exceed max  extra data buffer,cut it to max buffer size ", __FUNCTION__, __LINE__);
                pcodec->audio_info.extradata_size =  AUDIO_EXTRA_DATA_SIZE;
            }
		 pcodec->audio_info.extradata[0] = 0x02;
            memcpy((char*)pcodec->audio_info.extradata+3, map.data, pcodec->audio_info.extradata_size);
        }
        gst_buffer_unmap(info->configdata, &map);
    }
	pcodec->audio_info.extradata_size= pcodec->audio_info.extradata_size +3;
    pcodec->audio_info.valid = 1;
    return 0;	
}
gint vorbis_startcode(AmlStreamInfo* info, codec_para_t *pcodec, GstBuffer *buffer)
{
	gint32 buf_size;
    char head[] = "HEAD";

    codec_write(pcodec, head, 4);
    buf_size = gst_buffer_get_size(buffer);
    codec_write(pcodec, &buf_size, 4);

    return 0;

}

sorry for the type setting, Could you help to review the codes above? I know little about reference counts of buffers and buffer operation .Could you give me more info indetail?

There's not enough context to say anything about this code. One possible problem is this though:

> info->configdata =                    
>     gst_buffer_make_writable(gst_value_get_buffer(header_val));

With this you invalidate the buffer that is inside the array inside the caps, and as such later usage of the caps causes problems. Copy the buffer here instead of example.

Also below you do g_value_dup_boxed() (which is ok), but you forget to unref the buffer. So would leak it.

Thanks I will try what you said.
Here is the context.
for vorbis, streamheader consists value arry with num=3;
I have to get the three buffers data from the three value arry and then copy to one buffer called info->configdata; The initial there bytes of info->configdata must be 0x02 、 the second buffer size、the third buffer size to initialize  my decoder.

I know what that code is doing, but not what else is around it :) That's what I meant with context. I can only guess

Thanks, it works!

Also your two other bugs?

Yes closed thanks