Random Access Violation?

[Nathan Wild 3]

I recently deployed a new build of an application which has been running in the wild for some time now.  For some reason this build triggers an access violation in one of the DLLs that the ODBC connection to our database uses.  The only difference I can think of is that this version of the application was built with 10.1 Berlin and the previous was with 10-Seattle.  The code up to and including where the exception is thrown has not changed.  Anyone have even an idea how to troubleshoot this?

 

 

More details:

- The exception is in w3odbci.dll, part of Pervasive SQL's ODBC client.

- It is thrown when I am trying to open a very simple query with one parameter (SELECT Password FROM table WHERE UserID=:USERID)

- If I bypass this query, the same exception is thrown when I tries to open any other query

 

Any help appreciated!

 

 

[vfbb 285]

For random AV, I would say you have a multithreaded application without correct synchronization.

[David Heffernan 2345]

6 hours ago, vfbb said:

For random AV, I would say you have a multithreaded application without correct synchronization.

One of many possible explanations, but far from the only one. 

[Nathan Wild 3]

This is not a multithrreaded application.  Or at least my application is not.  Is suppose it is possible the ODBC interface is for some reason?

[David Heffernan 2345]

45 minutes ago, Nathan Wild said:

This is not a multithrreaded application.  Or at least my application is not.  Is suppose it is possible the ODBC interface is for some reason?

No reason at all to suspect that multithreading is the issue here. You aren't likely to get good leads from people making random guesses. Hard debugging is the way forward. 

[Nathan Wild 3]

4 minutes ago, David Heffernan said:

No reason at all to suspect that multithreading is the issue here. You aren't likely to get good leads from people making random guesses. Hard debugging is the way forward. 

Agreed...  I am just not sure how to approach debugging an access violation that is coming from an external library like that 😞

 

[David Heffernan 2345]

So often this is caused by a defect in your code. You supply an argument that is invalid. Perhaps an object that has already been destroyed. So full fastmm4 debug is useful. 

 

You would debug this by trying to create a minimal example that reproduces the issue. That's the starting point. 

[timfrost 78]

I have had a similar problem with external DLLs.  In our case we already had an exception handler in the calling C program which caught the exception and could display the stack in our log file.  For Delphi main programs, we also use MadExcept which can do the same thing, as do functions available in the JCL.  Then use something like Process Explorer to display the load addresses of all the external DLLs in the process before the exception occurs, and DUMPBIN /Exports to display all the entry points of the DLLs involved in the stack.  None of this will solve the problem on its own, but having the names of even a few of the functions that appear in the exception stack may give you some clues.   The simplest possible example, as David H suggests, will also help.

[Lars Fosdal 1792]

Just to rule out any db access issues - have you tried logging into the database with the same user credential and connection settings as your ODBC connection uses and running the query manually?

 

[Arnaud Bouchez 407]

As David wrote, try to make a minimal reproducible example.

Just a project with ODBC access, running a SELECT query.

 

I thought it may have been some problem with FPU exceptions, which happen with third-party libraries, but they usually occur in your Delphi code, not in library code....

Edited March 30, 2020 by Arnaud Bouchez

[Nathan Wild 3]

On 3/30/2020 at 2:09 AM, Lars Fosdal said:

Just to rule out any db access issues - have you tried logging into the database with the same user credential and connection settings as your ODBC connection uses and running the query manually?

 

Yes, I have tried this.  Connections to the same ODBC datasource using ADO components work fine.  It is only with FireDAC for some reason?

[Lars Fosdal 1792]

Do you use MadExcept or Eurekalog or similar?
There might be hints in the nature of the callstacks.

[Nathan Wild 3]

On 3/30/2020 at 2:09 AM, Lars Fosdal said:

Just to rule out any db access issues - have you tried logging into the database with the same user credential and connection settings as your ODBC connection uses and running the query manually?

 

Yes, I have tried this.  Connections to the same ODBC datasource using ADO components work fine.  It is only with FireDAC for some reason?

[Nathan Wild 3]

Update: I pulled the last working version of my application out of version control and rebuilt it with Berlin (previous was Seattle).  The original Seattle build works fine on the affected computers.  The new build - with no changes other than rebuilding it in Berlin - exhibits the same access violation.  Any idea what could have changed that would trigger this exception in a 3rd party DLL?

[Attila Kovacs 629]

AV's are cool, because you have the address.

btw, did you look for pervasive/windows logs?

[Nathan Wild 3]

2 hours ago, Attila Kovacs said:

AV's are cool, because you have the address.

btw, did you look for pervasive/windows logs?

Indeed... having the address is nice, except it's an address inside someone else's code 😞

 

And yes, I did look on the Pervasive logs.  Nothing at all of any use.  The PvSQL DLL is not catching this exception either.  So frustrating!!

[Lars Fosdal 1792]

How about using MadExcept or EurekaLog ?

[Cristian Peța 103]

I don't understand. Have you reproduced this on your machine? Then you can debug and see the call stack.

If not, then as @Lars Fosdal said: get MadExcept or EurekaLog and don't waste your time.

I dot't know how EurekaLog is but with MadExcept you need only to install it and check the checkbox that you want it in your app. That's all. Then you will have a full call stack to see where this happens in your code.

[Vandrovnik 214]

2 hours ago, Cristian Peța said:

I don't understand. Have you reproduced this on your machine? Then you can debug and see the call stack.

If not, then as @Lars Fosdal said: get MadExcept or EurekaLog and don't waste your time.

I dot't know how EurekaLog is but with MadExcept you need only to install it and check the checkbox that you want it in your app. That's all. Then you will have a full call stack to see where this happens in your code.

But he wrote that error happens in external .dll when he opens a query, not in his code.

[Vandrovnik 214]

Does AV happen on one computer, or all? Every query, or just some (with parameters? with string result? with only integer result? etc.)?