iotivity-lite icon indicating copy to clipboard operation
iotivity-lite copied to clipboard

Fatal signal 11 (SIGSEGV) in Android's iotivity library

Open Askidea opened this issue 2 years ago • 2 comments

Hello everyone!

In the GetRequestHandler part or initPost() processing, a fatal error occurs in the line below and the app crashes. There is no error like this in previous versions, v2.2.4.3 or earlier. This error related to the test case CTT "CT2.2.3 Partial UPDATE Message based on CoAP".

error line ===>> OcCborEncoder root = OcCborEncoder.createOcCborEncoder(OcCborEncoder.EncoderType.ROOT);

[My build environments ]

  • branch : master
  • commit: 29ccbf3 (latest as of 9/23)
  • iotivity lib build options : all=1 or (CLOUD=0 TCP=0 others=1) iotivity-lite/port/android$ make NDK_HOME=~/toolchains/ndk25-android-arm-23 ANDROID_API=23 DEBUG=1 SECURE=1 IPV4=1 TCP=1 PKI=1 DYNAMIC=1 CLOUD=1 JAVA=1 IDD=1

[Logcat : OCRequestHandler part] 2022-09-23 16:38:17.162 13130-13228/? D/GetLightRequestHandler: inside Get Light Request Handler 2022-09-23 16:38:17.163 13130-13228/? I/ServerActivity: ------------------------------------------------------------ 16:38:17.162 2022-09-23 16:38:17.163 13130-13228/? I/ServerActivity: Get Light: 2022-09-23 16:38:17.164 13130-13228/? I/ServerActivity: ZigBee-Light@SM-A710K, OFF, dimming=50 2022-09-23 16:38:17.165 13130-13228/? I/iotivity-lite-java/jni/oc_rep_wrap.c <jni_begin_root_object:338>: JNI: jni_begin_root_object 2022-09-23 16:38:17.166 13130-13228/? A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 13228 (Thread-5)

[Logcat: initPost() part] 2022-09-23 15:18:23.096 30465-30465 E/OCFClientService: doPost() : dt=oic.d.switch, uri=/BinarySwitchResURI, query=[rt=oic.r.switch.binary] 2022-09-23 15:18:23.097 30465-30465 I/iotivity-lite-java/jni/oc_endpoint_wrap.c <jni_string_to_endpoint_a:310>: JNI: jni_string_to_endpoint_a 2022-09-23 15:18:23.098 30465-30465 I/iotivity-lite-java/jni/oc_iotivity_lite_jni.c <jni_list_add:436>: JNI: - lock jni_list_add 2022-09-23 15:18:23.099 30465-30465 I/iotivity-lite-java/jni/oc_iotivity_lite_jni.c <jni_list_add:440>: JNI: - unlock jni_list_add 2022-09-23 15:18:23.099 30465-30465 I/iotivity-lite-java/jni/oc_api_wrap.c <jni_oc_init_post:1162>: JNI: jni_oc_init_post 2022-09-23 15:18:23.099 30465-30465 I/iotivity-lite-java/jni/oc_api_wrap.c <jni_oc_init_post:1163>: JNI: - lock jni_oc_init_post 2022-09-23 15:18:23.099 30465-30465 I/../../messaging/coap/transactions.c <coap_new_transaction:91>: Created new transaction 2864: 0xe5effb60 2022-09-23 15:18:23.099 30465-30465 I/../../api/oc_blockwise.c <oc_blockwise_init_buffer:65>: block-wise buffer allocated with size 16384 2022-09-23 15:18:23.103 30465-30465 I/iotivity-lite-java/jni/oc_rep_wrap.c <jni_begin_root_object:338>: JNI: jni_begin_root_object 2022-09-23 15:18:23.105 30465-30465 A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 30465 (ient:apiservice), pid 30465 (ient:apiservice)

Anyone involved in this issue would be very grateful for a quick review and resolution of the issue.

Askidea avatar Sep 23 '22 08:09 Askidea

I think this commit - https://github.com/iotivity/iotivity-lite/commit/d349ec91961d25ba76339f767d752f6af74b381e#diff-82d018ba0de8e0bd03ba54e7695dc4d77777346ce4c14a8247fa1d7091c53b59 - is the culprit. If you check oc_rep.h then new oc_rep_encode_* functions were created and all calls to cbor_encode_* were rewritten to oc_rep_encode_* calls. However, this wasn't done to the jni_* calls. I do have some urgent work though, so the soonest I can get to this is by the end of the next week.

(Anyway, we constantly seem to forget about the Java bindings when code is updated. It'd be for the best to develop a test case that runs with the Java bindings that runs with other tests when something is pushed to the repository. Hopefully, it's possible to develop something like that.)

Danielius1922 avatar Sep 23 '22 13:09 Danielius1922

@Askidea this should be fixed by https://github.com/iotivity/iotivity-lite/pull/328 .

I've also found that we had some JUnit tests for the Java bindings. The tests were commented out, but re-enabled them. So at least the baseline functionality covered by the tests should be guaranteed to work. (The tests run on a Linux machine, but I'd like them to run also on a Android device/emulator, because of the implementation differences between the platforms. But I don't yet how to do that, I'll do it some other time.)

Danielius1922 avatar Oct 14 '22 14:10 Danielius1922