Jump to content
Nathan Wild

Random Access Violation?

Recommended Posts

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!

 

 

Share this post


Link to post

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

Share this post


Link to post
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. 

  • Like 1

Share this post


Link to post

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?

Share this post


Link to post
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. 

Share this post


Link to post
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 😞

 

Share this post


Link to post

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. 

Share this post


Link to post

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.

Share this post


Link to post

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?

 

Share this post


Link to post

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 by Arnaud Bouchez

Share this post


Link to post
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?

Share this post


Link to post

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

Share this post


Link to post
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?

Share this post


Link to post

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?

Share this post


Link to post
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!!

Share this post


Link to post

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.

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post

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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×