Languages

Menu
Sites
Language
강제 종료 오류건

SAP를 사용하여 Native Wearable app을 개발하고 있습니다.

Sample 의 SAP Application 을 Base로 개발 중인데

아래 Call Stack 정보로 어플이 계속 강제종료되고 있습니다.

SAP 통신 후 바로 발생하기도 하고, 통신 후 한참 후 현상이 발생하기도 합니다.

특정 코드로 인해 발생하는게 아니듯 하여

혹시 아래 정보로 추측이 가능하시다면 조언 요청드립니다.

더 필요한 정보 있으시면 답글 부탁드립니다.

 

== Crash 정보 ==

1. Header

 1) S/W Version Information

  - Tizen-Version 2.3.1.0

 2) Signal Information

   - 11(SIGSEGV)si_code: 1address not mapped to objectsi_addr = 0x4

 

2. Call Stack Information

Callstack Information (PID:9190)
Call Stack Count: 16
 0: sap_wrapper_app_auth_indication_cb + 0x33 (0x415ad8a0) [/usr/lib/libsap-client-stub-api.so.1] + 0xa8a0
 1: (0x415a7429) [/usr/lib/libsap-client-stub-api.so.1] + 0x4429
 2: (0x41809da5) [/usr/lib/libsap_client.so.0] + 0x2da5
 3: g_simple_async_result_complete + 0x68 (0x40b75bed) [/usr/lib/libgio-2.0.so.0] + 0x4cbed
 4: (0x40bac961) [/usr/lib/libgio-2.0.so.0] + 0x83961
 5: g_simple_async_result_complete + 0x68 (0x40b75bed) [/usr/lib/libgio-2.0.so.0] + 0x4cbed
 6: (0x40b75ca1) [/usr/lib/libgio-2.0.so.0] + 0x4cca1
 7: (0x403b6fcf) [/usr/lib/libglib-2.0.so.0] + 0x33fcf
 8: g_main_context_dispatch + 0xbc (0x403b87a9) [/usr/lib/libglib-2.0.so.0] + 0x357a9
 9: (0x402fed57) [/usr/lib/libecore.so.1] + 0x10d57
10: (0x402f9b8f) [/usr/lib/libecore.so.1] + 0xbb8f
11: (0x402fa5e7) [/usr/lib/libecore.so.1] + 0xc5e7
12: ecore_main_loop_begin + 0x30 (0x402fa8b9) [/usr/lib/libecore.so.1] + 0xc8b9
13: appcore_efl_main + 0x3be (0x40045bb7) [/usr/lib/libappcore-efl.so.1] + 0x3bb7
14: ui_app_main + 0xb0 (0x41186421) [/usr/lib/libcapi-appfw-application.so.0] + 0x2421
15: main + 0x124 (0x414debad) [/opt/usr/apps/com.bccard.mobilecard.tizenwatch/bin/esewatch] + 0x11bad
End of Call Stack

 

3. Debug Message

...

09-09 23:45:24.005+0900 I/ESE_WATCH( 2204): sap.c: send_data(1091) > Sending data 
09-09 23:45:24.005+0900 F/ESE_WATCH( 2204): send_data() message (... json data...)
09-09 23:45:24.035+0900 F/ESE_WATCH( 2204): send_data() result (0)~!!
09-09 23:45:24.035+0900 I/ESE_WATCH( 2204): esewatch.c: update_ui(511) > Updating UI with data {... json data ...}
09-09 23:45:24.370+0900 D/RESOURCED(  612): logging.c: logging_send_signal_to_data(1088) > [logging_send_signal_to_data,1088] logging timer callback function start
09-09 23:45:24.370+0900 I/RESOURCED(  612): logging.c: logging_send_signal_to_data(1097) > [logging_send_signal_to_data,1097] send signal to logging data thread
09-09 23:45:24.370+0900 D/RESOURCED(  612): logging.c: logging_send_signal_to_update(1168) > [logging_send_signal_to_update,1168] logging timer callback function start
09-09 23:45:24.370+0900 I/RESOURCED(  612): logging.c: logging_send_signal_to_update(1177) > [logging_send_signal_to_update,1177] send signal to logging update thread
09-09 23:45:24.490+0900 W/CRASH_MANAGER( 2404): worker.c: worker_job(1199) > 1102204657365144180992

Edited by: Seong Jun Bang on 09 Sep, 2015

Responses

2 Replies
daniel kim

안녕하세요.

Segmentation Fault가 뜬 것으로 봐서 메모리가 깨지면서 죽는 것 같은데요..

call stack information에 나오는 주소를 가지고 backtrace하는 방법이 있으면 해당 source line을 찾을 수 있을 것 같은데, 찾아봐도 방법이 나오지 않는 것 같습니다.

 

 

daniel kim

sdb shell로 들어가서 dlogutil을 켜놓고 문제가 발생될 때 출력되는 log를 한번 살펴보시는 건 어떨까 합니다.