Application crashes with Exception pointing to libgstapp_1_0_0!gst_app_src_end_of_stream

[Luca Bacci]

My 2 cents...

Could this be a threading issue? Make sure that the thread that feeds
buffers to appsrc also sets the eos on appsrc. Otherwise, If the calls to
gst_app_src_push_bufffer() and gst_app_src_end_of_stream() are from
different threads, you can protect the two calls with a GMutex or a
CRITICAL_SECTION.

Just guessing

Il mar 7 gen 2020, 14:15 Mailing List SVR <lists at svrinformatica.it> ha
scritto:

> Il 24/12/19 09:58, hemanth.chandrashekar at in.unisy ha scritto:
> > Hello,
> >
> > We have one of our Windows application integrated with "G-Streamer
> 1.12.0"
> > and is running fine both on test/production system.
> >
> > As the load on system/G-Streamer increases, we are facing the application
> > crash. On analyzing the dump file, it is pointing to one of the method
> call
> > from G-Streamer.
> >
> > *** ERROR: Symbol file could not be found.  Defaulted to export symbols
> for
> > c:\gstreamer\1.0\x86\bin\libgstapp-1.0-0.dll -
> > libgstapp_1_0_0!gst_app_src_end_of_stream+0x1c:
> >
> > FAULTING_MODULE: 772b0000 ntdll
> >
> > DEBUG_FLR_IMAGE_TIMESTAMP:  590c30b7
> >
> > ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced
> > memory at 0x%p. The memory could not be %s.
> >
> > EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p
> referenced
> > memory at 0x%p. The memory could not be %s.
> >
> > EXCEPTION_PARAMETER1:  00000000
> >
> > EXCEPTION_PARAMETER2:  80000358
> >
> > READ_ADDRESS:  80000358
> >
> > FOLLOWUP_IP:
> > libgstapp_1_0_0!gst_app_src_end_of_stream+1c
> > 703c349c 8b13            mov     edx,dword ptr [ebx]
> >
> > BUGCHECK_STR:  APPLICATION_FAULT_INVALID_POINTER_READ_WRONG_SYMBOLS
> >
> > PRIMARY_PROBLEM_CLASS:  INVALID_POINTER_READ
> >
> > DEFAULT_BUCKET_ID:  INVALID_POINTER_READ
> >
> > LAST_CONTROL_TRANSFER:  from 0168a214 to 703c349c
> >
> >
> > We are curious how to identify the root cause of this issue. Although it
> > takes some effort to recreate this issue, we can still see the problem
> with
> > load on the consistence failure.
> >
> > I was reading in some portals if we can get some help without luck.
> > Appreciate if you can review and comment..
> >
> > Code snippet where "gst_app_src_end_of_stream" is invoked ...
> >
> > *static bool handleTerminateRequest(const wstring &reason,
> > VnmsStreamProcessor *proc)
> > {
> >       GstFlowReturn ret;
> >       /* we are EOS, send end-of-stream and remove the source */
> >       TR_TRACE( informTrace, 0, proc->Port << reason);
> >       ret = gst_app_src_end_of_stream((GstAppSrc*)proc->source);
>
> maybe proc->source was previously unreffed and so it is not valid anymore,
>
> regards
> Nicola
>
> >       if (ret != GST_FLOW_OK)
> >       {
> >               TR_TRACE( errorTrace, 0, proc->Port <<
> L"handleTerminateRequest: error
> > pushing end-of-stream buffer : " << ret);
> >       }
> >       SetEvent(proc->hInputDataProcessedEvent);
> >       return FALSE;
> > }*
> >
> > Regards,
> > Hemanth
> >
> >
> >
> > --
> > Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200107/f0e6f111/attachment-0001.htm>