-
Notifications
You must be signed in to change notification settings - Fork 605
avs-sdk-crash in speaking/thinking state #391
Comments
I have ran MediaPlayer test and below are the logs for the similar crash: 2017-12-09 08:08:28.013 [ 1] 0 MediaPlayer:handleSetObserverCalled (gdb) bt |
Hi @dhananjayj29, Would it be possible for you to upgrade to v1.3? We've made significant stability improvements in this release and we believe it should solve the crash you are seeing. If not, could you give me some reproduction steps so that I can try to reproduce locally? Thanks, |
Hi Below are the logs 2017-12-08 23:27:08.369 [ 10] I InProcessAttachmentReader:readFailed:reason=SDS is closed
|
Hi @dhananjayj29, Unfortunately, I was unable to reproduce this in my environment. However, it looks the error is coming from here. Could you maybe sprinkle in some log messages in there to see exactly when/where the promise is being set twice? From what I'm seeing in the code, anytime a promise is set, it immediately returns. Thanks, |
Hi @dhananjayj29 |
Thanks anu-mathur I filled the form. |
I have added the logs in the suggested functions as below: void MediaPlayer::handlePlay(SourceId id, std::promise* promise) {
Below are the details of crash ######################################## 2017-12-19 15:14:42.570 [ 3] 1 AlertsCapabilityAgent:executeOnConnectionStatusChanged:status=CONNECTED,reason=ACL_CLIENT_REQUEST Listening...############################ 2017-12-19 15:15:16.804 [ 12] 9 AudioInputProcessor:onFocusChanged:newFocus=FOREGROUND Thinking...########################### 2017-12-19 15:15:20.527 [ 10] I InProcessAttachmentReader:readFailed:reason=SDS is closed 2017-12-19 15:15:21.548 [ 2] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 15:15:21.548 [ 2] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 15:15:21.548 [ 2] 0 MediaPlayer:handlePlayCalled before set state 2 times it crashed with below logs: :20:22.266 [ 9] 0 AudioInputProcessor:setState:from=IDLE,to=RECOGNIZING Listening...############################ 2017-12-19 15:20:22.297 [ 10] 0 HTTP2Transport:processNextOutgoingMessage:jsonContent={"context":[{"header":{"namespace":"Speaker","name":"VolumeState"},"payload":{"volume":100,"muted":false}},} Thinking...########################### 2017-12-19 15:20:26.718 [ 10] I InProcessAttachmentReader:readFailed:reason=SDS is closed 2017-12-19 15:20:27.773 [ 2] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 15:20:27.773 [ 2] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 15:20:27.773 [ 2] 0 MediaPlayer:handlePlayCalled before set state 2017-12-19 15:20:27.773 [ 2] 0 MediaPlayer:handlePlay:attemptBuffering=0 and single time it stuck with below logs: 17-12-19 15:23:05.767 [ c] 9 SpeechSynthesizer:preHandleDirective:messageId=10439ed8-cb51-42dc-852b-0983d033a224 2017-12-19 15:23:05.776 [ 2] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 15:23:05.776 [ 2] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 15:23:05.776 [ 2] 0 MediaPlayer:handlePlayCalled before set state 2017-12-19 15:23:05.776 [ 2] 0 MediaPlayer:handlePlay:attemptBuffering=0 |
Hi |
@dhananjayj29 , looking into the issue, do you still see it when your run MediaPlayer tests? or only from the Sample App interaction. |
Hi mradulan , crash 1: [==========] Running 35 tests from 1 test case. crash 2: Pl provide some pointer , i want to fix this in some urgency |
what is the version of gstreamer? |
gstreamer along with all gst plugins 1.10.4 |
Hi @dhananjayj29, Looking through the code, I really don't see any code paths that could cause a promise to be set twice. For example, in play(), a local stack std::promise variable is created and passed into a separate function as a pointer. This is the same for each function (resume(), pause(), etc.). In those separate functions, any time a promise value is set, it appears to return immediately. I'm a little confused about how this could be happening unless GStreamer is invoking that same function twice. Could you possibly provide some sort stack trace from the point at which the exception is thrown? If you could run the code in some sort of debugger and paste the stack trace when the exception occurs, that might be helpful. Another possible helpful thing would be to log the address of each promise pointer that is passed into One more question - is this crash only happening on your embedded linux environment or other environments as well? Also, what version of GCC are you using? Thanks, |
Here are the answers of you questions:
stack trace from where the Play function is called: (gdb) bt #0 0xb6b8ed08 in __pthread_cond_wait (cond=0xb3601ca0, mutex=0x0) at pthread_cond_wait.c:187
|
Here are the logs for MediaPlayerTest: [==========] Running 35 tests from 1 test case. 2017-12-19 11:49:40.343 [ 1] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 11:49:40.343 [ 1] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 11:49:40.343 [ 1] 0 MediaPlayer:handlePlayCalled before set state 2017-12-19 11:49:40.351 [ 1] 0 MediaPlayer:handlePlay:attemptBuffering=0 2017-12-19 11:49:43.579 [ 3] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 11:49:43.579 [ 3] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 11:49:43.579 [ 3] 0 MediaPlayer:handlePlayCalled before set state 2017-12-19 11:49:43.579 [ 3] 0 MediaPlayer:handlePlay:attemptBuffering=0 2017-12-19 11:49:46.451 [ 3] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 11:49:46.451 [ 3] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 11:49:46.451 [ 3] 0 MediaPlayer:handlePlayCalled before set state 2017-12-19 11:49:46.451 [ 3] 0 MediaPlayer:handlePlay:attemptBuffering=0 2017-12-19 11:49:49.355 [ 4] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 11:49:49.355 [ 4] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 11:49:49.355 [ 4] 0 MediaPlayer:handlePlayCalled before set state 2017-12-19 11:49:49.355 [ 4] 0 MediaPlayer:handlePlay:attemptBuffering=0 2017-12-19 11:49:54.565 [ 5] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 11:49:54.565 [ 5] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 11:49:54.565 [ 5] 0 MediaPlayer:handlePlayCalled before set state 2017-12-19 11:49:54.565 [ 5] 0 MediaPlayer:handlePlay:attemptBuffering=0 2017-12-19 11:49:56.803 [ 6] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 11:49:56.803 [ 6] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 11:49:56.803 [ 6] 0 MediaPlayer:handlePlayCalled before set state 2017-12-19 11:49:56.803 [ 6] 0 MediaPlayer:handlePlay:attemptBuffering=0 2017-12-19 11:49:57.986 [ 6] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 11:49:57.986 [ 6] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 11:49:57.986 [ 6] 0 MediaPlayer:handlePlayCalled before set state 2017-12-19 11:49:57.987 [ 6] 0 MediaPlayer:handlePlay:attemptBuffering=0 2017-12-19 11:49:59.184 [ 7] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 11:49:59.184 [ 7] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 11:49:59.184 [ 7] 0 MediaPlayer:handlePlayCalled before set state 2017-12-19 11:49:59.185 [ 7] 0 MediaPlayer:handlePlay:attemptBuffering=0 2017-12-19 11:50:00.384 [ 8] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 11:50:00.385 [ 8] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 11:50:00.385 [ 8] 0 MediaPlayer:handlePlayCalled before set state 2017-12-19 11:50:00.385 [ 8] 0 MediaPlayer:handlePlay:attemptBuffering=0 2017-12-19 11:50:03.155 [ 9] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 11:50:03.156 [ 9] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 11:50:03.156 [ 9] 0 MediaPlayer:handlePlayCalled before set state 2017-12-19 11:50:03.156 [ 9] 0 MediaPlayer:handlePlay:attemptBuffering=0 2017-12-19 11:50:03.620 [ a] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 11:50:03.620 [ a] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 11:50:03.620 [ a] 0 MediaPlayer:handlePlayCalled before set state 2017-12-19 11:50:03.620 [ a] 0 MediaPlayer:handlePlay:attemptBuffering=0 2017-12-19 11:50:03.832 [ b] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 11:50:03.832 [ b] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 11:50:03.832 [ b] 0 MediaPlayer:handlePlayCalled before set state 2017-12-19 11:50:03.833 [ b] 0 MediaPlayer:handlePlay:attemptBuffering=0 2017-12-19 11:50:04.022 [ c] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 11:50:04.022 [ c] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 11:50:04.022 [ c] 0 MediaPlayer:handlePlayCalled before set state 2017-12-19 11:50:04.022 [ c] 0 MediaPlayer:handlePlay:attemptBuffering=0 2017-12-19 11:50:05.258 [ e] 0 MediaPlayer:handlePlayCalled after gst_element_get_state 2017-12-19 11:50:05.258 [ e] 0 MediaPlayer:handlePlayCalled after GST_STATE_PLAYING 2017-12-19 11:50:05.258 [ e] 0 MediaPlayer:handlePlayCalled before set state 2017-12-19 11:50:05.258 [ e] 0 MediaPlayer:handlePlay:attemptBuffering=0 I can see the same promise being used in multiple methods, though it is stack variable. |
regarding the ubuntu 14.04 , I am having some issue with the setup today for v1.3 version and could not get the logs. so for ubuntu 14.04 m still not sure whether same issue occurs or not. As previous testing for ubuntu 14.04 was done on v1.1.0 and there I found multiple issues with promise setting which were resolved in v1.3 version. |
Hi @dhananjayj29, Thanks for confirming. It doesn't really seem to be a code or I've been searching around and couldn't find any known issues around GCC 4.8.2 about this sort of behavior unfortunately. I wonder if it would be possible to allocate the std::promises differently, maybe as a heap variable instead to guarantee a different address be used. Thanks, |
used heap variables .. and fixed this issue |
Hi @dhananjayj29, I am also facing the same issue on embedded environment (arm7l with openwrt using AVS device sdkVersion: 1.6.0). Can you please share the fixes you did about using std::promises as heap variable. It will be really helpful for me. Thank in advance |
Hi @dhananjayj29, I have the similar issue porting avs device sdk (version 1.9.0) on an Amlogic board. Could you please share your fix about using std::promises as heap variable. Thanks. |
Hi ,
I have built avs-sdk and sample app for my Linux embedded system environment.
sdk version : 1.2.1
while running the sample app through command line interface , am getting the crash after every 2-3 queries . below are the detailed logs and stack trace for my crash .
below are the logs , SDK is crashing so frequently here:
2018-01-08 23:18:36.847 [ a] 9 MediaPlayer:playCalled
2018-01-08 23:18:36.848 [ 2] 0 MediaPlayer:handlePlayCalled:idPassed=1,currentId=1
2018-01-08 23:18:36.848 [ 2] 0 MediaPlayer:handlePlay:attemptBuffering=0
2018-01-08 23:18:36.864 [ 2] 0 MediaPlayer:handlePlay:startingState=PLAYING,stateReturn=ASYNC
2018-01-08 23:18:36.864 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:36.864 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:36.864 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:36.865 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:36.865 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:36.865 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:36.867 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:36.867 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:36.867 [ 2] 9 MediaPlayer:State Change:oldState=NULL,newState=READY,pendingState=PLAYING
2018-01-08 23:18:36.867 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:36.867 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:36.867 [ 2] 9 MediaPlayer:messageReceived:messageType=stream-status
2018-01-08 23:18:36.867 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:36.868 [ 14] 9 BaseStreamSource:onNeedDataCalled:size=4096
2018-01-08 23:18:36.868 [ 2] 9 MediaPlayer:messageReceived:messageType=stream-status
2018-01-08 23:18:36.868 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:36.868 [ 2] 9 MediaPlayer:messageReceived:messageType=stream-status
2018-01-08 23:18:36.868 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:36.868 [ 2] 9 MediaPlayer:messageReceived:messageType=stream-status
2018-01-08 23:18:36.868 [ 2] 9 BaseStreamSource:handleNeedDataCalled
2018-01-08 23:18:36.868 [ 2] 9 BaseStreamSource:installOnReadDataHandler:action=newSourceId,sourceId=16
2018-01-08 23:18:36.869 [ 2] 9 AttachmentReaderSource:read:size=4096,status=0
2018-01-08 23:18:36.869 [ 2] 9 AttachmentReaderSource:read:size=4096,status=0
2018-01-08 23:18:36.869 [ 2] 9 AttachmentReaderSource:read:size=4096,status=0
2018-01-08 23:18:36.869 [ 2] 9 AttachmentReaderSource:read:size=3185,status=0
2018-01-08 23:18:36.930 [ 14] 9 MediaPlayer:onPadAddedCalled
2018-01-08 23:18:37.223 [ 2] 9 AttachmentReaderSource:read:size=4096,status=0
2018-01-08 23:18:37.224 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.224 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.224 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.224 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.224 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.224 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.225 [ 2] 9 AttachmentReaderSource:read:size=4096,status=0
2018-01-08 23:18:37.225 [ 2] 9 MediaPlayer:handlePadAddedSignalCalled
2018-01-08 23:18:37.244 [ 2] 9 AttachmentReaderSource:read:size=4096,status=0
2018-01-08 23:18:37.245 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.245 [ 2] 9 AttachmentReaderSource:read:size=4096,status=0
2018-01-08 23:18:37.247 [ 2] 9 MediaPlayer:messageReceived:messageType=stream-start
2018-01-08 23:18:37.529 [ 2] 9 AttachmentReaderSource:read:size=4096,status=0
2018-01-08 23:18:37.529 [ 10] 0 AudioInputProcessor:onSendCompleted:status=SUCCESS
2018-01-08 23:18:37.530 [ 10] 0 HTTP2Transport:cleanupFinishedStream:streamId=9,result=200
2018-01-08 23:18:37.530 [ 2] 9 MediaPlayer:messageReceived:messageType=latency
2018-01-08 23:18:37.530 [ 2] 9 MediaPlayer:messageReceived:messageType=stream-status
2018-01-08 23:18:37.530 [ 2] 9 MediaPlayer:messageReceived:messageType=tag
2018-01-08 23:18:37.530 [ 2] 0 MediaPlayer:callingOnTags
2018-01-08 23:18:37.531 [ 2] 9 MediaPlayer:messageReceived:messageType=tag
2018-01-08 23:18:37.531 [ 2] 0 MediaPlayer:callingOnTags
2018-01-08 23:18:37.531 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.531 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.531 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.531 [ 2] 9 MediaPlayer:State Change:oldState=READY,newState=PAUSED,pendingState=PLAYING
2018-01-08 23:18:37.531 [ 2] 9 MediaPlayer:messageReceived:messageType=async-done
2018-01-08 23:18:37.532 [ 2] 9 MediaPlayer:messageReceived:messageType=new-clock
2018-01-08 23:18:37.530 [ 10] 0 HTTP2StreamPool:releaseStream:streamId=9,numAcquiredStreams=1
2018-01-08 23:18:37.532 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.532 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.532 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.532 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.533 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.533 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.533 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.533 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.533 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.533 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.533 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.533 [ 2] 9 MediaPlayer:messageReceived:messageType=state-changed
2018-01-08 23:18:37.534 [ 2] 9 MediaPlayer:State Change:oldState=PAUSED,newState=PLAYING,pendingState=VOID_PENDING
2018-01-08 23:18:37.534 [ 2] 0 MediaPlayer:callingOnPlaybackStarted:currentId=1
2018-01-08 23:18:37.534 [ 2] 9 SpeechSynthesizer:onPlaybackStarted:callbackSourceId=1
2018-01-08 23:18:37.534 [ a] 0 SpeechSynthesizer:executePlaybackStarted
2018-01-08 23:18:37.534 [ 2] 9 MediaPlayer:messageReceived:messageType=tag
2018-01-08 23:18:37.534 [ a] 0 SpeechSynthesizer:executeProvideState:stateRequestToken=0
2018-01-08 23:18:37.534 [ a] 9 MediaPlayer:getOffsetCalled
2018-01-08 23:18:37.534 [ 2] 0 MediaPlayer:callingOnTags
2018-01-08 23:18:37.534 [ 2] 9 AttachmentReaderSource:read:size=1388,status=0
2018-01-08 23:18:37.535 [ 2] 0 MediaPlayer:handleGetOffsetCalled:idPassed=1,currentId=1
2018-01-08 23:18:37.537 [ a] 0 ContextManager:updateStateLocked:action=updatedState,state={"token":"amzn1.as-ct.v1.Domain:Application:Knowledge#ACRI#1681976a-a9b0-48d7-9905-d9600e680406#Alexa3P:1.0/2e
2018-01-08 23:18:37.537 [ 13] 9 SpeechSynthesizer:onFocusChangedSuccess
2018-01-08 23:18:37.537 [ a] 0 EventBuilder:buildJsonEventString:messageId=5e253201-b5df-47ae-9663-105c8ad1889d,namespace=SpeechSynthesizer,name=SpeechStarted
2018-01-08 23:18:37.537 [ a] 9 HTTP2Transport:enqueueRequest:jsonContent={"event":{"header":{"namespace":"SpeechSynthesizer","name":"SpeechStarted","messageId":"5e253201-b5df-47ae-9663-105c8ad1889}
2018-01-08 23:18:37.538 [ 2] I InProcessAttachmentReader:readFailed:reason=SDS is closed
2018-01-08 23:18:37.878 [ 2] 9 AttachmentReaderSource:read:size=0,status=3
2018-01-08 23:18:37.878 [ 2] 9 BaseStreamSource:signalEndOfDataCalled
2018-01-08 23:18:37.878 [ 10] 0 HTTP2Transport:processNextOutgoingMessage:jsonContent={"event":{"header":{"namespace":"SpeechSynthesizer","name":"SpeechStarted","messageId":"5e253201-b5df-47ae-9663}
2018-01-08 23:18:37.879 [ 10] 0 HTTP2StreamPool:getStream:streamId=11,numAcquiredStreams=2
2018-01-08 23:18:37.879 [ 2] 9 BaseStreamSource:clearOnReadDataHandlerCalled:sourceId=16
terminate called after throwing an instance of 'std::future_error'
2018-01-08 23:18:37.879 [ 10] 9 HTTP2
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:57
#1 0xb6a52950 in __GI_abort () at abort.c:89
#2 0xb6c3a58c in __gnu_cxx::__verbose_terminate_handler () atgcc-4.8.2-r0/gcc-4.8.2/libstdc++-v3/libsupc++/vterminate.cc:95
#3 0xb6c383d8 in __cxxabiv1::__terminate (handler=) at /gcc-4.8.2/libstdc++-v3/libsupc++/eh_terminate.cc:38
#4 0xb6c38400 in std::terminate () at /gcc-4.8.2-r0/gcc-4.8.2/libstdc++-v3/libsupc++/eh_terminate.cc:48
#5 0xb6c8ca84 in std::(anonymous namespace)::execute_native_thread_routine (__p=)
atmp-eglibc/work-shared/gcc-4.8.2-r0/gcc-4.8.2/libstdc++-v3/src/c++11/thread.cc:92
#6 0xb6eeb040 in start_thread (arg=0xae2ff440) at pthread_create.c:314
#7 0xb6af10e0 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/clone.S:92 from //lib/libc.so.6
#8 0xb6af10e0 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/clone.S:92 fromlib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Can someone help to find out root cause and possible fix for this issue.
The text was updated successfully, but these errors were encountered: