libplctag: Segmentation fault from unlocking / destroying tags from a thread
Hello. I am using the latest release (1.5.2) and am experiencing a segmentation fault from unlocking and destroying tags. I compiled with debugging (-g) and ran it with gdb and got the following back trace output:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa7368b40 (LWP 6194)]
0xa784b49c in send_eip_request_unsafe () from /usr/local/lib/libplctag.so
(gdb) bt
#0 0xa784b49c in send_eip_request_unsafe () from /usr/local/lib/libplctag.so
#1 0xa7849113 in session_send_current_request () from /usr/local/lib/libplctag.so
#2 0xa78493bf in session_check_outgoing_data_unsafe () from /usr/local/lib/libplctag.so
#3 0xa784945f in process_session_tasks_unsafe () from /usr/local/lib/libplctag.so
#4 0xa784952a in request_handler_func () from /usr/local/lib/libplctag.so
#5 0xa7d06d97 in start_thread (arg=0xa7368b40) at pthread_create.c:309
#6 0xa764f64e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129
I will attach the relevant files in the zip file. The destroy function seg faults instead of blocking at least! That is an improvement in my opinion.
libplctag seg fault on close.zip
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 17 (17 by maintainers)
Commits related to this issue
- Added acquire/release for requests actively being sent. This, hopefully, will fix issue #45: crashes under certain cases of calling plc_tag_destroy(). The theory was that a request could be deleted w... — committed to libplctag/libplctag by kyle-github 7 years ago
- fixes #45 — committed to libplctag/libplctag by kyle-github 4 years ago
No worries. The first bug report back in January was definitely a bug in the library. A royal @#% pain to repro, but very real. I was removing a buffer while another thread was still using it. That was the primary fix in 1.5.3 and it came completely from your bug report.
Thanks for the report!
I will try to replicate it. From the log it looks like it might be very timing dependent. The seg fault is within the IO thread which is decoupled from anything done with the client side of the API. So, that limits where it could be happening. I suspect that the unlock might not have anything to do with it. Calling the destroy function though…