Application crashes with Exception pointing to libgstapp_1_0_0!gst_app_src_end_of_stream

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);
        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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Hi, Appreciate your feedback Thanks, Hemanth

---

Sent from the GStreamer-devel mailing list archive at Nabble.com.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mailing List SVR]

Il 24/12/19 09:58, [hidden email] 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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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 <[hidden email]> ha scritto:

Il 24/12/19 09:58, [hidden email] 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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel