[BUG]: latest Commit from MASTER crash

[sujitdiwakar]

Gdb CRASH:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 11352]
0x77a5fb54 in pthread_mutex_lock () from target:/lib//libpthread.so.0
(gdb) bt
#0 0x77a5fb54 in pthread_mutex_lock () from target:/lib//libpthread.so.0
#1 0x00b08704 in defaultLockMutex (mutex=0)
at /home/shiv/project/ingenic/ingenic_main_branch_540/camera/opensource/amazon-webrtc-sdk-c/open-source/libkvsCommonLws/build/src/libkvsCommonLws-download/dependency/libkvspic/kvspic-src/src/utils/src/Mutex.c:195
#2 0x00ac77f8 in connectionListenerReceiveDataRoutine (warning: GDB can't find the start of the function at 0x77a5dc5f.

GDB is unable to find the start of the function at 0x77a5dc5f

and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x77a5dc5f for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
arg=0x1e1d008)
at /home/shiv/project/ingenic/ingenic_main_branch_540/camera/opensource/amazon-webrtc-sdk-c/src/source/Ice/ConnectionListener.c:301
#3 0x77a5dc60 in ?? () from target:/lib//libpthread.so.0

Describe the bug: My System running in long run for 24 hours after 24 for hours of running i tried live streaming. its start live streaming and few seconds after its crash.

SDK version number: commit ID: f3a34c2

compiled on 32 bit mips arch

To Reproduce
Steps to reproduce the behavior:

1. keep running for more than 24 hours
2. start live streaming after 24 hrs
3. its crash

[MushMal]

The stack trace does not contain enough information to make sense as to what's happening.

• Could you include the values of locals?
• Include the dump trace of all of the threads
• More description of the scenario when this happens. We do have streams that are running for a long time but haven't seen this crash.

From the trace provided it's not clear what's crashing. If the mutex has been freed then we would have exited the select and the previous check in LN 300 would have failed. I need to do a little more tracing to get more info but if this is something that's reproducible on your side then we would need a little more info to work on.

[MushMal]

I can only explain this if you see the following line:

https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/blob/master/src/source/Ice/SocketConnection.c#L78

If you do then the only explanation is that either:

1. Your select call in https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/blob/master/src/source/Ice/ConnectionListener.c#L291 does not respect the timeout (check your platform)
2. Your socket should be non-blocking but actually does block in https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/blob/master/src/source/Ice/ConnectionListener.c#L308

In both of the above cases, it's platform related and you might want to check why your socket is blocking

[hassanctech]

@sujitdiwakar Closing due to staleness. Please re-open if you are still having problems and you're able to provide the information requested by @MushMal.