I am trying to solve onResume error in my game created by Cocos2d-x. When i go background and come back to game then game is crashed. and log-cat are as followed.
11:49:10.997 E/cocos2d-x: cocos2d: warning, Director::setProjection() failed because size is 0
11:49:11.001 D/Cocos2dxActivity: onWindowFocusChanged() hasFocus=true
11:49:11.020 D/FA: Connected to remote service
11:49:11.020 V/FA: Processing queued up service tasks: 4
11:49:11.062 D/Cocos2dxActivity: onPause()
11:49:11.064 D/AudioFocusManager: abandonAudioFocus succeed!
11:49:11.077 D/Cocos2dxActivity: onWindowFocusChanged() hasFocus=false
11:49:11.080 V/FA: onActivityCreated
11:49:11.087 I/SDKBOX_CORE: Sdkbox Droid starting.
11:49:11.087 I/SDKBOX_CORE: Sdkbox got VM.
11:49:11.087 I/SDKBOX_CORE: Initialize is called more than once.
11:49:11.094 D/Cocos2dxActivity: model=MotoE2
11:49:11.094 D/Cocos2dxActivity: product=otus_reteu_ds
11:49:11.094 D/Cocos2dxActivity: isEmulator=false
11:49:11.099 D/AutoManageHelper: starting AutoManage for client 0 false null
11:49:11.103 D/AutoManageHelper: onStart true {0=com.google.android.gms.internal.zzbau$zza#2efa3200}
11:49:11.106 D/Cocos2dxActivity: onResume()
11:49:11.109 D/AudioFocusManager: requestAudioFocus succeed
11:49:11.187 D/Cocos2dxActivity: onWindowFocusChanged() hasFocus=true
11:49:11.208 V/FA: Screen exposed for less than 1000 ms. Event not sent. time: 360
11:49:11.214 V/FA: Activity paused, time: 2492571
11:49:11.215 V/FA: Activity resumed, time: 2492614
11:49:11.674 D/cocos2d-x: reload all texture
11:49:11.674 E/cocos2d-x: cocos2d: warning, Director::setProjection() failed because size is 0
11:49:11.706 D/cocos2d-x debug info: Cocos2d-x-lite v1.6.0
11:49:12.411 A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x1aa in tid 16084 (GLThread 1061)
11:49:12.411 A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 16061 (GLThread 1048)
I always see these two error logs.
11:49:12.411 A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x1aa in tid 16084 (GLThread 1061
11:49:11.674 E/cocos2d-x: cocos2d: warning, Director::setProjection() failed because size is 0
I have already tried this but does not work.
cocos2d-x game crashes when entered background
Related
Recently I add a broadcast upload extension to my host app to implement system wide screen cast.I found the broadcast upload extension sometimes stopped for unknown reason.If I debug the broadcast upload extension process in Xcode, it stopped without stopping at a breakpoint（If the extension is killed for 50M bytes memory limit, it will stopped at a breakpoint, and Xcode will point out that it's killed for 50M bytes memory limit）.For more imformation, I read the console log line by line.Finally, I found a significant line:
osanalyticshelper Process replayd [26715] killed by jetsam reason highwater
It looks like the ReplayKit serving process 'replayd' is killed by jetsam, and the reason is 'highwater'.So I searched the internet for more imformation.And I found a post:
https://www.jianshu.com/p/30f24bb91222
After reading that,I checked the JetsamEvent report in device, and found that when the 'replayd' process was killed it occupied 100M bytes memory.Is there a 100M bytes memory limit for 'replayd' process?How can I avoid it to occupy more than 100M bytes memory?
Further more, I found that this problem offen occured if the previous extension process is stopped via RPBroadcastSampleHandler's finishBroadcastWithError method.If I stop the extension via control center button, this rarely occured.
As comparison, when the 'Wemeet' app stop it's broadcast upload extension, it raraly cause this problem.I compared the console log when 'Wemeet' stop it's broadcast extension and the log my app stop it's broadcast extension.I found this line is different:
Wemeet:
mediaserverd MEDeviceStreamClient.cpp:429 AQME Default-InputOutput: client stopping: <ZenAQIONodeClient#0x1080f7a40, sid:0x3456e, replayd(30213), 'prim'>; running count now 0
My app:
mediaserverd MEDeviceStreamClient.cpp:429 AQME Default-InputOutput: client stopping: <ZenAQIONodeClient#0x107e869a0, sid:0x3464b, replayd(30232), 'prim'>; running count now 3
As we can see, the 'running count' is different.
have this error in AmazonDynamoDBLockClient. Im using org.springframework.cloud:spring-cloud-stream-binder-kinesis:2.0.1.RELEASE
#Spring Cloud Stream Kinesis Binder properties
spring.cloud.stream.bindings.cdcInput.group=listener
spring.cloud.stream.bindings.cdcInput.destination=my_stream
spring.cloud.stream.bindings.cdcInput.content-type=application/json
spring.cloud.stream.kinesis.binder.auto-create-stream=false
spring.cloud.stream.kinesis.binder.locks.table=LockRegistry
spring.cloud.stream.kinesis.binder.checkpoint.table=MetadataStore
spring.cloud.stream.kinesis.binder.locks.leaseDuration=10
spring.cloud.stream.kinesis.binder.locks.heartbeat-period=3
and here is my application.properties configs
com.amazonaws.services.dynamodbv2.AmazonDynamoDBLockClient - Heartbeat thread recieved interrupt, exiting run() (possibly exiting thread)
java.lang.InterruptedException: sleep interrupted
java.lang.Thread.sleep(Native Method)
com.amazonaws.services.dynamodbv2.AmazonDynamoDBLockClient.run(AmazonDynamoDBLockClient.java:1184)
java.lang.Thread.run(Thread.java:748)
[SpringContextShutdownHook] INFO org.springframework.integration.aws.inbound.kinesis.KinesisMessa
geDrivenChannelAdapter - stopped KinesisMessageDrivenChannelAdapter{shardOffsets=[KinesisShardOffset{iteratorType=TRIM_HORIZON, sequenceNumber='null', timestamp=null, stream='binlog_updates', shard='shardId-000000000000', reset=false}], consumerGroup='cdc-listener'}
[-kinesis-shard-locks-1] ERROR org.springframework.integration.aws.inbound.kinesis.KinesisMessageD
rivenChannelAdapter - Error during unlocking: DynamoDbLock [lockKey=cdc-listener:rds_binlog_updates:shardId-000000000000,lockedAt=2021-01-21#15:54:36.735, lockItem=null]
org.springframework.dao.DataAccessResourceFailureException: Failed to release lock at cdc-listener:binlog_updates:shardI
d-000000000000; nested exception is java.util.concurrent.RejectedExecutionException: Task org.springframework.integration.aws.lock.DynamoDbLockRegistry$DynamoDbLock$ reject
ed from java.util.concurrent.ThreadPoolExecutor#[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 1]
org.springframework.integration.aws.lock.DynamoDbLockRegistry$DynamoDbLock.unlock(DynamoDbLockRegistry.java:526)
org.springframework.integration.aws.inbound.kinesis.KinesisMessageDrivenChannelAdapter$ShardConsumerManager.run(KinesisMessageDrivenChannelAdapter.java:1294)
We are getting this error even if the stream is empty and no data is read by consumer. Service starts application context as regular without any errors, but in 1-2 minutes such an error appears and application falls down.
To debug a locked file problem, we're calling SysInternal's Handle64.exe 4.11 from a .NET process (via Process.Start with asynchronous output redirection). The calling process hangs on Process.WaitForExit because the Handle64 process doesn't exit (for more than two hours).
We took a dump of the corresponding Handle64 process and checked it in the Visual Studio 2017 debugger. It shows two threads ("Main Thread" and "ntdll.dll!TppWorkerThread").
Main thread's call stack:
ntdll.dll!NtWaitForSingleObject () Unknown
ntdll.dll!LdrpDrainWorkQueue() Unknown
ntdll.dll!RtlExitUserProcess() Unknown
kernel32.dll!ExitProcessImplementation () Unknown
handle64.exe!000000014000664c() Unknown
handle64.exe!00000001400082a5() Unknown
kernel32.dll!BaseThreadInitThunk () Unknown
ntdll.dll!RtlUserThreadStart () Unknown
Worker thread's call stack:
ntdll.dll!NtWaitForSingleObject() Unknown
ntdll.dll!LdrpDrainWorkQueue() Unknown
ntdll.dll!LdrpInitializeThread() Unknown
ntdll.dll!_LdrpInitialize() Unknown
ntdll.dll!LdrInitializeThunk() Unknown
My question is: Why would a process hang in LdrpDrainWorkQueue? From https://stackoverflow.com/a/42789684/62838, I gather that this is the Windows 10 parallel loader at work, but why would it get stuck while exiting the process? Can this be caused by how we invoke Handle64 from another process? I.e., are we doing something wrong or is this rather a bug in Handle64?
How long did you wait?
According to this analysis,
The worker thread idle timeout is set to 30 seconds. Programs which
execute in less than 30 seconds will appear to hang due to
ntdll!TppWorkerThread waiting for the idle timeout before the process
terminates.
I would recommend trying to set the registry key specified in that article to disable the parallel loader and see if this resolved the issue.
Parent Key: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\handle64.exe
Value Name: MaxLoaderThreads
Type: DWORD
Value: 1 to disable
While running my app in the background fetch, after a few fetches i receive the following error. Im using iOS 10.2.1 and Xcode Version 8.2.1
I have enabled background fetch in capabilities. Would anyone be able to tell me why its happening?
2017-02-02 14:28:09.738682 ********* [446:57355] [] nw_socket_get_input_frames recvmsg(fd 15, 1024 bytes): [57] Socket is not connected
2017-02-02 14:28:09.738979 *********[446:57355] [] nw_socket_write_close shutdown(15, SHUT_WR): [57] Socket is not connected
2017-02-02 14:28:09.739172 *********[446:57355] [] nw_endpoint_flow_service_writes [6.1 216.58.193.74:443 ready socket-flow (satisfied)] Write request has 0 frame count, 0 byte count
2017-02-02 14:28:09.739522 *********[446:64570] [] __tcp_connection_write_eof_block_invoke Write close callback received error: [89] Operation canceled
I'm running an app on iOS and periodical (not very often) it crashes with EXC_BAD_ACCESS.
The crash occurs while starting boost::thread:
boost::thread(boost::bind(&SomeClass::someStaticFunction, someParam));
and the call stack i see is:
* thread #35: tid = 0x2a822, 0x00d2469e NdsVgconnectTestApp`boost::(anonymous namespace)::thread_proxy(param=<unavailable>) + 246 at thread.cpp:164, stop reason = EXC_BAD_ACCESS (code=1, address=0x20000008)
* frame #0: 0x00d2469e NdsVgconnectTestApp`boost::(anonymous namespace)::thread_proxy(param=<unavailable>) + 246 at thread.cpp:164
frame #1: 0x3b877918 libsystem_pthread.dylib`_pthread_body + 140
frame #2: 0x3b87788a libsystem_pthread.dylib`_pthread_start + 102
I'm passing to boost::thread a static function so its hard to believe that there is some problem with addressing or pointer corruption. So my question is: Can EXC_BAD_ACCESS crash be an artifact of iOS device running out of memory or the app exceeding the memory limit given by the OS?