v2.5.2: nRF9160 Azure IoTHub: Crash after TOPIC_TWIN_REPORTED

CD Feather9160, Azure IoTHub using DPS.  Last part of the console log:

[00:00:06.667,419] <dbg> azure_iot_hub: azure_iot_hub_connect: User name buffer size is 160, actual user name size is: 132
[00:00:06.679,016] <inf> nrf_modem: getaddrinfo() fam: 0x0, type 0x1, proto 0x6
[00:00:06.794,921] <inf> nrf_modem: RPC_IP_GETADDRINFO_RES, result RPC_IP_ERR_OK
[00:00:06.802,886] <inf> nrf_modem: Resolved 13.69.230.66
[00:00:06.808,868] <inf> nrf_modem: socket() fam 0x1, type 0x1, proto 0x102
[00:00:06.816,650] <inf> nrf_modem: RPC_IP_OPEN_RES, result RPC_IP_ERR_OK
[00:00:06.824,005] <inf> nrf_modem: connect() fd 0x0
[00:00:06.829,437] <inf> nrf_modem: sa_family 0x1, destaddr_len 0x4, destport 8883
[00:00:06.981,872] <inf> nrf_modem: RPC_IP_CONNECT_RES fd 0x0, result RPC_IP_ERR_OK
[00:00:06.990,051] <inf> nrf_modem: Attaching sock fd 0x0
[00:00:07.017,974] <inf> nrf_modem: RPC_IP_TLS_ATTACH_RES fd 0x0, result RPC_IP_ERR_OK
[00:00:08.615,570] <inf> nrf_modem: RPC_IP_TLS_HANDSHAKE_COMPLETE_NTF fd 0x0, result RPC_IP_ERR_OK
[00:00:08.625,122] <inf> nrf_modem: send() fd 0x0, len 185, blocking
[00:00:08.632,812] <inf> nrf_modem: RPC_IP_SEND_RES fd 0x0, result RPC_IP_ERR_OK
[00:00:08.640,747] <inf> nrf_modem: send() fd 0x0, 185 bytes sent
[00:00:08.647,338] <inf> centralstation: Connection request sent to IoT Hub
[00:00:08.782,104] <inf> nrf_modem: RPC_IP_RECVFROM_NTF, fd 0x0 (4 bytes)
[00:00:08.789,459] <inf> nrf_modem: recv() fd 0x0, buf 0x200106e8, len 2, flags 64 (non-block)
[00:00:08.798,583] <inf> nrf_modem: recv() fd 0x0, buf 0x200106ea, len 2, flags 64 (non-block)
[00:00:08.807,739] <dbg> azure_iot_hub: iot_hub_state_set: State transition: STATE_CONNECTING --> STATE_CONNECTED
[00:00:08.818,481] <dbg> azure_iot_hub: on_connack: MQTT mqtt_client connected
[00:00:08.826,293] <inf> nrf_modem: send() fd 0x0, len 127, blocking
[00:00:08.833,709] <inf> nrf_modem: RPC_IP_SEND_RES fd 0x0, result RPC_IP_ERR_OK
[00:00:08.841,644] <inf> nrf_modem: send() fd 0x0, 127 bytes sent
[00:00:08.848,205] <dbg> azure_iot_hub: topic_subscribe: Successfully subscribed to default topics
[00:00:08.857,666] <inf> centralstation: AZURE_IOT_HUB_EVT_CONNECTED
[00:00:08.924,102] <inf> nrf_modem: RPC_IP_RECVFROM_NTF, fd 0x0 (8 bytes)
[00:00:08.931,457] <inf> nrf_modem: recv() fd 0x0, buf 0x200106e8, len 2, flags 64 (non-block)
[00:00:08.940,582] <inf> nrf_modem: recv() fd 0x0, buf 0x200106ea, len 6, flags 64 (non-block)
[00:00:08.949,737] <inf> centralstation: AZURE_IOT_HUB_EVT_READY
[00:00:08.956,268] <dbg> azure_iot_hub: request_id_create_and_get: Request ID not specified, using "895"
[00:00:08.966,308] <inf> nrf_modem: send() fd 0x0, len 30, blocking

As you can see, I'm connected and all seems to be well. The last output from azure_iot_hub is around this code:

	case AZURE_IOT_HUB_TOPIC_TWIN_REPORTED: {
		char request_id[20];
		char *request_id_ptr = msg->request_id.ptr;
		size_t request_id_len = msg->request_id.size;
		az_span request_id_span;

		if (msg->request_id.size == 0) {
			err = request_id_create_and_get(request_id, sizeof(request_id));
			if (err) {
				LOG_ERR("Failed to create request ID");
				return -ENOMEM;
			}

			request_id_ptr = request_id;
			request_id_len = strlen(request_id);
		}

Going through the debugger (gdb w/ BMP), I see that the actual crash occurs when calling strlen(). Doing a step also causes a crash.

Debugger:


^C
Program received signal SIGINT, Interrupt.
0x000122d2 in ?? ()
(gdb) bt
#0 0x000122d2 in ?? ()
#1 0x000123c0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info thread
Id Target Id Frame
* 1 Thread 1 0x000122d2 in ?? ()
(gdb) 

i.e. no information. Looking at zephyr.map, it could be around:

 .debug_loc     0x0000000000012397     0x156d zephyr/libzephyr.a(log_output.c.obj)

but I have no way of knowing. The appilcation does _not_ reboot. Nor does it continue executing.

Please help.

Mikael

 

Parents Reply Children
No Data
Related