Re: iACS ODBC Driver on Linux: Segfault in libcwbcore.so

Do you know if your developer is using the ADO.Net<http://ADO.Net> ODBC connectivity or trying to use Entity Framework ?

I seem to recall Entity Framework didn’t have a layer for ODBC.

Also depending on how often they are calling services I wonder if their coding could be inducing the ODBC issues by overloading things.

Or possibly they are trying to use the same open ODBC connection with multiple threads. That seems like it could cause issues.

Without seeing their code it’s hard to say.

Also not sure if they are trying connection pooling or not.

Posting the question here might help as Korinne Adler knows a lot about ODBC, as does Calvin Buckley who hosts the site:
https://chat.ibmioss.org

Regards,
Richard Schoen
Web: http://www.richardschoen.net
Email: richard@xxxxxxxxxxxxxxxxx

message: 2
date: Wed, 2 Jul 2025 14:20:29 +0200
from: Patrik Schindler <poc@xxxxxxxxxx>
subject: Re: iACS ODBC Driver on Linux: Segfault in libcwbcore.so

Hello Richard,

Am 02.07.2025 um 02:24 schrieb Richard Schoen <richard@xxxxxxxxxxxxxxxxx>:

Make sure to report back here once you resolve your situation.

Thanks for your interest.

The programmer refactored the database connector code according to Microsoft specs, instead of doing a short cut, as before. This step seemed to fix the issue. But when he increases the number of worker threads in the application two orders of magnitude, it again crashes in libcwbcore.so after some minutes of runtime. With only a handful of threads, the application ran for almost a week without issue. My personal opinion is that the problem is not solved.

Re-testing with a high number of threads, and playing with the threading parameter in odbcinst.ini up to three proves that configuring the "threading" parameter doesn't solve the issue. Strange.

There is some evidence from debug "printf" that the crash happens at connection open time.

In the end, the decision which level of remaining crash risk is acceptable ? vs. putting hours and hours into what seems endlessly drilling down which side effects might trigger the issue until we eventually need to give up ? when we finally reached the binary IBM driver blob ? is not mine.

It feels really botchy, but I bet we need to work around the issue by a watchdog, restarting the application, if it's gone. That's a boss-thing to decide. I'm just an advisor. :-)

I suppose the other option would be to create your data service natively on i.

Then you?re just using REST calls.

To put it politely, the .NET guy is? reluctant to deviate from his comfort zone using C#, .NET, Blazor and his IDE. :-)

I also suggested to stop using threads and do it like e. g. Apache has worked for decades: Using processes, where the dispatcher and workers are confined into their own memory area. But "that's not how you do it today". Personally, I don't care how exactly he manages to get the application into a stable state. :-)

Also, there is the "if you want things to be done right, do them yourself" approach, by implementing a TCP client for whatever wire protocol IBM i talks on TCP port 8471. Unfortunately, I haven't found any documentation regarding the actual protocol. So far I suspect it might be a derivate of DRDA.

Or try the MAPEPIRE web sockets server.

Thanks, have put this on the pile of possible alternate solutions.

:wq! PoC