You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 2019-02-27 07:51:56
- squirrel
- Member
- Registered: 2015-08-13
- Posts: 146
Mysql Access Violation
This is not a bug report or complaint, but a request for information from other that might have experienced something similar. I'm really fishing for ideas on where to look, since lots of logging and debugging didn't really help so far.
I experience "random" access violations when running queries with parameters on Mysql. The software runs at several customers on very different platforms (mostly Win7, 10, and server 2016) and versions of MySql (mostly either 5.5 or 5.7). It sometimes happens after it has been running for days and sometimes after weeks.
Initially I thought it might be a problem in the Odbc driver (again, this happens on a range of versions from ancient to the latest), so I switched from using TSQLDBConnectionProperties with the Odbc drivers to using TSQLDBFireDACConnectionProperties with the MySql client dll. It looks like the switch to TSQLDBFireDACConnectionProperties did reduce the number of times this happens, but that is more a gut feel than based on data.
I was able to determine that this does not happen with select statements (TSQLDBConnectionProperties.Execute), just Inserts and Updates and always only when there are at least 10 parameters involved (TSQLDBConnectionProperties.ExecuteNoResult). All the parameters are either strings or integers, no nulls or empty strings. After the programs are restarted, those same queries with the same parameters all execute without problems for a few days. What I have found with select statements though, is that when used with parameters via TSQLDBConnectionProperties , they sometimes return empty result sets where data should have been returned. However, with TSQLDBFireDACConnectionProperties, those same queries always return the correct data.
It looks as like after the A/V happens, that specific connection is tainted, so maybe something got freed and an attempt is made to reuse it? Maybe this happens while deleting old connections in the pool? I've tried executing TSQLDBConnectionProperties.ClearConnectionPool after the A/V to attempt to force new connections to be made, but with no success.
So far, I have been unable to reliably replicate the issue. Any advice from anybody that experienced something similar that could give an idea on maybe how to trigger it more often so I can debug it better would help a lot.
Offline
#2 2019-02-27 09:00:16
Re: Mysql Access Violation
What is the exact call stack at the Access Violation?
(you can use SynLog to write it, or try third parties like madexcept)
Which compiler do you use?
Do you use the latest version of the framework?
Did you try to run your program with FastMM4 in FullDebugMode (or FPC with heaptrc flag), and see if there is no memory corruption?
Offline
#3 2019-02-27 10:45:24
- squirrel
- Member
- Registered: 2015-08-13
- Posts: 146
Re: Mysql Access Violation
I use Delphi 10.3, but this has been a thorn in my side for a few months, so also had the issue with Delphi 10.2 and older versions of the framework. The most recent site where this happened was built with a nightly build downloaded on 2019-02-14. In which file is the build and version number saved, so I can paste it here?
I'll get more up to date logs for the full call stacks and post when it happens again. I even had traces showing the issue happening in ntdll.dll (which is unlikely, probably just bubbled up from odbc drivers). But this caused me to think that maybe there might be a reference to a parameter that gets freed before the query is passed to the driver. Since most of the sites still use the 32bit version, I can not currently specifically rule the 64bit version in or out.
Was just trying to find out if others have experienced something similar which can help me to replicate it, which would make debugging possible. I've never had it appear in the lab while compiled in debug mode, always only the release versions on clients' premises.
Offline
Pages: 1