pylogix: Random segmentation fault (core dumped) in ARM64

I have tested on Raspberry Pi 3B, armv7l, nothing goes wrong, both in Docker and outside Docker. I’ll close this issue. Thank you all.

I pushed a commit that should take care of this BOOL array in list issue.

@dmroeder did a bit of troubleshooting this morning, I can confirm latest 0.7.7 there’s a bug for boolean list read. #154 will def prevent this in the future as far as testing goes.

C:\git\pylogix>py -3.7 pylogix/testing/test.py

########### List Read

BaseBOOLArray[0] True Success
BaseBOOLArray[1] False Success
BaseBOOLArray[2] False Success
BaseBOOLArray[3] False Success
BaseBOOLArray[4] None Path destination unknown
BaseBOOLArray[5] None Path destination unknown
BaseBOOLArray[6] None Path destination unknown
BaseBOOLArray[7] None Path destination unknown

########### Array Read

BaseBOOLArray[0] [True, False, True, False, True, False, True, False, True, False] Success

However the same test passes fine in 0.7.5:

########### List Read

BaseBOOLArray[0] True Success
BaseBOOLArray[1] False Success
BaseBOOLArray[2] False Success
BaseBOOLArray[3] False Success
...
BaseBOOLArray[124] True Success
BaseBOOLArray[125] False Success
BaseBOOLArray[126] True Success
BaseBOOLArray[127] True Success

########### Array Read

BaseBOOLArray[0] [True, False, True, False, True, False, True, False, True, False] Success

Happy new year!

@dmroeder @TheFern2

I found this issue, https://github.com/python-pillow/Pillow/issues/1935 maybe we can get something from it, something about docker container privileged or stack size control.

Sorry, I mistouch the close button on my phone.

I think we have multiple layers here.

First we need to establish that your code that reads tags works fine from a laptop without using docker. I’m talking just pylogix and reading a list of tags, do not add any db, opc, or any other logic.

If that code works fine without docker, next is to try it on docker again just pylogix. If that gives you a seg fault then is definitely a docker issue.

https://dev.to/mizutani/how-to-get-core-file-of-segmentation-fault-process-in-docker-22ii

If pylogix works fine on both laptop and container, then add the other logic little by little, first db, then opc, etc. Containers are super fragile for example I’ve had a container that wouldn’t stat on just because a db wasn’t named properly.

Edit: I wrote all this before the last two responses.

Yes, we are doing the something as you said, and need time.

@TheFern2 you are right, there are two problems going on here. Reading and the segmentation fault.

Segmentation fault suggests that the python interpreter crashed. From my experience, this happens when a program which binds to some other language crashes. For example, OpenCV, where they have a python layer that binds to C. I don’t believe pylogix is causing the segmentation fault, something else is crashing.

Sleep is in seconds. 0.2 seconds = 200ms. 0.02 seconds = 20ms

pylogix is a pure python project. Full stack trace might be helpful as @TheFern2 points out.

One problem I see with your example, each time you are calling rockwellread(), you are creating a new instance of the driver while not closing it. The PLC will eventually flush the connections, but you are creating new connections faster than the PLC will flush them, it will eventually get tired of this.

Why read each tag individually and not just just read the whole list at once? It would be much faster to read the list.

import time
from pylogix import PLC

tag_list = ["Result_Value", "SwitchValue", "Time.Minute"]

def my_function(tag_list):
    ret = comm.Read(tag_list)
    return ret

with PLC("192.168.1.61") as comm:
    while True:
        x = my_function(tag_list)
        print(x)
        time.sleep(1)

Maybe the segfault comes from the IP stack? Since your code is running the read in a tight loop you may be overwhelming the device you are talking to. If this happens it might send garbage back.

Put something like time.sleep(0.020) in your loop and see if this prevents the segfault.