SIGPIPE exception

[J-Millett]

Using v3.0.1 of the aws-iot-device-sdk-embedded-C. This has build for arm-linux-gnueabihf.

I have found that there is a SIGPIPE exception which is being issued whilst running the libAWSIotSdk. The following is output received whilst running with gdb:

`Thread 38 "MQTTThreadProc" received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x6f9af450 (LWP 23816)]
0x767054f0 in write () at ../sysdeps/unix/syscall-template.S:84
84 ../sysdeps/unix/syscall-template.S: No such file or directory.

#0 0x767054f0 in write () at ../sysdeps/unix/syscall-template.S:84
#1 0x7630e976 in mbedtls_net_send () from ./lib/libMQTT.so
#2 0x76318ae6 in mbedtls_ssl_flush_output () from ./lib/libMQTT.so
#3 0x7631aa98 in mbedtls_ssl_write_record () from ./lib/libMQTT.so
#4 0x7631c8be in ssl_write_real () from ./lib/libMQTT.so
#5 0x7631c9c2 in mbedtls_ssl_write () from ./lib/libMQTT.so
#6 0x76286b62 in iot_tls_write () from ./lib/libAwsIotSdk.so
#7 0x76284fc2 in aws_iot_mqtt_internal_send_packet () from ./lib/libAwsIotSdk.so
#8 0x76285586 in _aws_iot_mqtt_internal_handle_publish () from ./lib/libAwsIotSdk.so
#9 0x76285628 in aws_iot_mqtt_internal_cycle_read () from ./lib/libAwsIotSdk.so
#10 0x76280710 in _aws_iot_mqtt_internal_yield () from ./lib/libAwsIotSdk.so
#11 0x76280832 in aws_iot_mqtt_yield () from ./lib/libAwsIotSdk.so
#12 0x762eb24e in MQTTThreadProc () from ./lib/libMQTT.so
#13 0x766fe5b4 in start_thread (arg=0x0) at pthread_create.c:335
#14 0x7619bc4c in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:89 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)`

All of my interactions with the libAWSIotSdk are protected in internal code via Mutexes however they are operating from different threads. There seems to be a race condition somewhere causing a broken pipe to be written to.

My first thought is to enable thread support using 'ENABLE_THREAD_SUPPORT' along with thread support from mbedtls using '#define MBEDTLS_THREADING_PTHREAD' and '#define MBEDTLS_THREADING_C'

Any additional information or advice is appreciated, especially if this is a known issue and hence the threading support able to be enabled above.

[abhidixi11]

Hello J-Millett ,
Thanks for contacting.
As I understand from the other ticket that it happens every 4-12 hrs? May I know what your application is doing ? Is it continuously active or it stays idle for long duration?
I'm trying to determine if the connection getting closed by the server and then application tries to use it.
Have you tried enabling thread support ?

Thanks.

[J-Millett]

It has been occurring in the range of 4-12 hours with units which heavily use MQTT. In units which don't have as heavy usage the range can be much longer term.

Currently we have a set up where we are publishing to two topics each minute, two topics every 15-20s and three other topics less commonly. Its fairly rare for the station to be idling without any MQTT use unless there is no network connection available which in testing is very rare.

We have turned threading support on now and are giving it some time so we can see if this sorts out the issue.

[abhidixi11]

Hello J-Millett,

Thanks for the response. Please update when you find out. Also, is it possible to get wire trace to determine if this is happening due to server disconnect?
Thanks.

[gordonwang0]

Hi @J-Millett,

You can ignore SIGPIPE by setting its signal handler to SIG_IGN. The library should work correctly with SIGPIPE masked.

[yuhui-zheng]

@J-Millett To keep debug session going at least, would you mind trying below setting in your GDB session --

(gdb) handle SIGPIPE nostop

(Refer to https://sourceware.org/gdb/download/onlinedocs/gdb/Signals.html)

It's a good question why our software does not provide default handler for SIGPIPE. We will evaluate potential update meanwhile.

[J-Millett]

For the moment we have not seen a re-occurrence of this issue whilst setting threading support on. I will continue to do some more testing and monitoring of the situation to see if the issue pops up again.

Thanks to everyone for the support so far.

[gordonwang0]

Hi @J-Millett,

Please let us know if you need any more help with this. Closing issue.