FYI Latest version will not run on Debian 12 due to GLIBC_2.38 version

[Nathan Fieldhouse]

So per title. Up to version 2.6.3 is fine but 2.6.4 requires GLIBC_2.38.

Debian 12 is stuck at 2.36 although a new version is coming is the next couple of months.

I think keeping Debian compatibility would be good as its a stable platform to run this on.

Thats just my thoughts any way :-)

[Kyle]

Thanks for bringing this up.   I automatically use the latest Ubuntu version in the CI build system and that looks like a bug now!   I will see what I can do to use older Ubuntu versions to build the pre-built binaries.

I filed a bug on this, 534.

Thanks again for bringing this up!

Best,

Kyle

[Kyle]

I will run it on Debian, but it looks like back-leveling the CI build image to Ubuntu 22.04 worked.   I will keep this in mind for future changes.

Best,

Kyle

[Nathan Fieldhouse]

Awesome thank you. I will try out the new version. Out of interest you mention the new version now using multi-threading, currently I have written an app that is accessing 9 AB plc's, each running in its own thread since version 2.4 what effect would this have?

Thanks

Nathan

[Kyle]

The library has been internally multithreaded since the 2.0 days (ten years?).   One of my tests is to test thousands of tags against 50 simulated PLCs.  Each PLC connection has its own thread to do IO.  You can use threads in your app if you want.   Unless you are really CPU bound in your app, you probably do not need to use threads in your app, at least for the PLC part.

The full release with these fixes will be version 2.6.6.  It is not out yet but as soon as I finish up the fix for restarting open requests after a reconnect, I will release it.

Best,

Kyle

[Kyle]

Please let me know if this is fixed for you.

Best,

Kyle

[Kyle]

Any luck with the 2.6.6 version on Debian?

Best,

Kyle

[Nathan Fieldhouse]

Hi Kyle,

Sorry I have not got back to you sooner, I was refactoring my handling of data types to improve things.

I finished my changes today and uploaded to my testing Debian server and after installing the new plctag library, I can report its working fine! Thank you for your help

[Nathan Fieldhouse]

I hate to be the bearer of bad news but I am getting General Protection Faults after a few minutes of trying to connect to a plc that is inaccessible with this release. The debugger is showing the fault occurs in libplctag. I dropped back to version 2.6.3 and the fault is gone. 
 

[Kyle]

Yikes!   This is definitely a problem.  Let me work on that.

I created bug 546 for this.

Thanks for bringing this up!   I will make sure I debug this on Debian.

Is your network fast?  I.e. very low latency on responses from the PLC?

Best,

Kyle

[Nathan Fieldhouse]

Hi Kyle,

To give you more information, the network is gigabit with 100mb to each PLC. 

This fault is being generated from trying to create the first tag but failing on timeout in which case it loops trying again.

I checked the stack and its -32 for the first response and it is correctly not continuing with the rest of tag list.

I do not get a General Protection fault if the PLC's are present and communicating.

[Nathan Fieldhouse]

Oh I forgot to mention, my developing machine is not Debian, its the latest stack. 

On Sunday, 29 June 2025 at 05:03:34 UTC+10 Kyle wrote:

[Kyle]

How long is the timeout?   I doubt that makes much of a difference, but all the data helps!

I suspect that this bug is due to the changes I made to support retries when PLCs go away.  I am surprised that the test did not pick this up though.  I do exactly the same test where tag handles are created with timeouts and the PLC is gone.   It is probably a race condition of some sort.  Sigh.

Best,

Kyle

[Kyle]

I have an idea of what it might be.  But I cannot seem to repro this.   I've tried doing what you said your code was doing and waiting up to 30 seconds for a crash and I am not getting it.

Can you give me more details on how the tag is being created?

I have what I think is a fix in place, but I need to run it through Valgrind a few times to make sure that nothing bad is happening.  

Would you be able to test if I gave you a 64-bit build for Ubuntu/Debian?

Best,

Kyle

[Nathan Fieldhouse]

Hi Kyle,

I just got home from work. 

I came across this accidentally, testing for something else in my program non PLC coms related. 

So didn't accidentally change something in the site PLC i was running the code offline on my laptop which will have a more update GLIBC than debian.

The program was crashing within 2 mins of running. It was trying to connect to two PLC's, one a Micrologix and the other a ControlLogix both with a timeout set to 500ms.

I then rolled back libplctag to 2.6.3, all was fine. To double check re installed 2.6.6, crashed once again pretty quick. Back to 2.6.3 - all fine.

Feel free to send me any thing you wish to test, no problem at all :-)

[Kyle]

Hmm. Two minutes... OK maybe I am not waiting long enough.  I have a program (from user Wegel) that checks for automatic reconnect.  To do that it uses the ab_server code.  It brings up the server, and has some tags connect and run.  Then it takes down the server for a while and then brings it back up.  All the auto sync tags will reconnect correctly. I added another test which does the same with synchronous tags.  It sounds like I need to wait longer.  I am only waiting 30 seconds.   Are there multiple threads trying to open the tags?

Best,

Kyle

[Nathan Fieldhouse]

Yes each PLC Tag processing runs in its own thread.

Regards

Nathan

[Nathan Fieldhouse]

Sorry I did not make that very clear. I create a thread per PLC, In this case there were two plc's one micrologix and one controllogix so two threads were running each trying to create a tag but as each tag was failing on time out the thread would retry after 100ms or so

[Nathan Fieldhouse]

Hi Kyle,

I have been running your new version in the exact same configuration as last time. Is has been running for 5 hrs with no GPF. I went back to previous version to prove it and

 it took just over 5 mins but it did crash, same fault as before. So new version definitely looking better!

[Kyle]

Thanks!!

This was really a pain to repro.  I never did get it to repro on my Mac.  I had to go to a Linux system and even then the only suspicious thing was that malloc's internal data structures looked corrupt.  It passed with all sanitizers on and even Valgrind would not catch anything.  But, the malloc implementation would flag corrupted internal data and crash.  I was finally able to get that to happen but I have to run the test for at least 90 seconds to consistently get it.  I run for 120 seconds. I've done hundreds of runs and 120 seconds always crashed.  So that is what is in the test now!

Thanks again for bringing this up.  As noted above, clearly my earlier tests were not sufficient. I will be looking at adding some sort of memory debugging tests as well.

Best,

Kyle

On Monday, July 7, 2025 at 6:28:58 AM UTC-7 2gd...@gmail.com wrote:

Hi Kyle,