PB8 app crashes with memory error.

Using PB8 Professional Version 8.0.1 Build 8004

Have application that we have been using for over a year.  Application connects to MySQL database.  We are having a problem with the application crashing with the error:

  The Instructions at "0x6540dd2d" referenced memory at "0x6540dd2d"
  The memory could not be "read"

  Click on OK to terminate
  Click on Cancel to debug

Have rebuilt application and get the same error.  The section of code this is failing in has not changed in quite some time.  It also fails with the same error at a few other points in the application.  

smatthesenAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

EAServerCommented:
smatthesen
That's not enough information...What is this section of code doing.  I'd suggest using the debugger to find out the line of code causing the problem.  Then let us know what that line of code is, perhaps then we can be of help.

Also, you are using a fairly old build of PB 8, you may want to consider upgrading to at least 8.0.2 it was a bit more stable, or just go to the latest and greatest.

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
smatthesenAuthor Commented:
Have run debugger to find the line that is doing this.  
The line it is crashing on is:

execute immediate :sql_str;

However, there are a few other places that it pops up.  It is not every time this application is run, but is often enough to warrant a fix (maybe 20%).  

Do you know of any problems going to 8.0.3?  I downloaded it the other day, but haven't run it as of yet.

Thanks,
Scott
0
EAServerCommented:
I know 8.0.3 had some memory leaks, caused by the new memory manager.  There have been some ebfs released to address those problems.  The only other thing is that the new memory manager named something like libjsybheap.dll must deployed with your application instead of the old libjcc.dll  Other than that, there are bug fixes in 8.0.3, and when you include the ebfs, it seems to be the most stable build.  It's probably worth a try perhaps on a separate workstation using a copy of the code, see if you can reproduce the issue.

As to your specific problem...This could be difficult to track down because that line of code is sending a dynamic SQL statement off to the database which complicates things a bit.  It becomes hard to identify if the problem is local when trying to communicate with the database, or when receiving and processing the result set or somewhere in between.  In theory, it could even be the database driver crashing and bringing PB with it.  Along those lines I noticed you are using MySQL.  In the past, I have had issues with MySQL when connecting via ODBC.  I have found that using JDBC is much more stable.  However, this was sometime ago, and both MySQL and the ODBC driver have probably been updated since then.  It may be worth taking a look at the JDBC driver, assuming you aren't already using it, if we can't seem to get by this issue.  Of course the problem with a switch like that this late in the game is that it requires a retest of the entire app.  But I thought I'd throw that out there.

Some things to look at that might help track the error down.  When you are using the debugger, can you verify that sql_str has a valid SQL statement when it crashes?  Another thing you can do is to turn on tracing for the database.  Prepend the keyword "Trace" to the DBMS property of your transaction object.  For instance if you are connecting using ODBC, the code would be...

sqlca.dbms = "Trace ODBC"

this will generate a file with all the sql sent to the database and some response information.  Then take a look at the file and see if it reveals anything useful.  Often, when you get an error during the execution of a database command, it is caused by the command being invalid, but PB fails to handle the DB error properly and crashes instead of handling it through the normal sqldbcode and sqlerrtext properties of the transaction object.  Coincidentially, I  had a similar problem with the same build of PB you are using.  I was dynamically modifying the update table for a datawindow, but I had a typeo when I set the primary key column.  When I called the update() function, the invalid SQL got sent to the database, but instead of PB handling the exception properly, it crashed.  I was using an ODBC connection to ASA.  Of course, invalid SQL may not be the cause of your problem but it is where I'd start looking, and a combination of the debugger and db trace will be a good place to start.

Hope this helps!
0
Cloud Class® Course: C++ 11 Fundamentals

This course will introduce you to C++ 11 and teach you about syntax fundamentals.

buasuwanCommented:
FYI,
PB 8.0.1 causes many problems. upgrading to 8.0.3 is the better way to void another problems that you will get.

here is about 8.0.3, and you will see 8.0.1 fixed problems.

http://www.pdriver.com/soft/pb803/pb803mr_fixes.htm

0
smatthesenAuthor Commented:
I did as EAServer suggested and ran with Trace on.

The last few lines I get before the app crashes are:

(6143c40): CANCEL: (0 MilliSeconds)
(6143c40): DISCONNECT: (0 MilliSeconds)
(6143c40): SHUTDOWN DATABASE INTERFACE: (0 MilliSeconds)
(3fe1f2c): EXECUTE:
(3fe1f2c): delete from barcodes where mbol in ('00401526640P') and customerid = 7

I went through the app enough that it failed twice.
Both times it had the CANCEL then DISCONNECT.
The app never issued a disconnect command.
Any ideas?

Thanks,
Scott
0
smatthesenAuthor Commented:
Missed a couple of lines.
These came right before the CANCEL

(6143c40): FETCH NEXT: (0 MilliSeconds)
(6143c40):
 Error 3 (rc 100)


0
EAServerCommented:
smatthesen
Well the (rc 100) would indicate that it was unable to find the record for the FETCH NEXT statement.  That's not bad, because that is how it knows where the end of the result set is. Unfortunately, it the does a SHUTDOWN DATABASE INTERFACE, which unloads the database driver.  Worse, PB is unaware the driver has been removed from memory so the next attempt at SQL crashes.  It seems that the problem isn't really with the code that causes the error but with the previous SQL statement that causes the database to close your connection.  That might explain why this seems to happen in several places, because it will always be the next SQL statement that causes the crash.


buasuwan
Trust me 8.0.3 has its own can of worms, especially pre ebfs.  But yes, overall it is more stable than 8.0.1 and addresses many errors, some that were published and some that were not.  Keep in mind though that anytime you upgrade to a new version you need to do regression testing because it could break something that had been working.
0
smatthesenAuthor Commented:
Have upgraded to 8.0.3 Build 9704
Have upgraded MyODBC driver from 2.50 to 3.51
Have tried newer version of MySQL (4.01 vs. 3.23)

Still no resolution to this problem.  I have dug a little deeper.  It seems that the places PB is crashing are all "EXECUTE IMMEDIATE :SQL_STR" lines.  Are there any known issues with this?  Also, any idea why this would have worked for a year and just now started having problems?  These sections of code haven't been touched in quite some time.  Sorry to keep this going, but I need some resolution to this problem.  Will give points to you guys when we get this figured out.  

EAServer,
I checked the SQL statements before this and they appear to be fine.  It is a Dynamic Cursor, the loop exits when the FETCH returns <> 0.  I then close the cursor and execute my next statement which is where I am getting the crash.

Thanks again,
Scott
0
EAServerCommented:
smatthesen

I'm still not convinced that the "EXECUTE IMMEDIATE :SQL_STR" is the culprit.  It is more of a victim of an unloaded database driver.  Try any SQL statement after that dynamic cursor and see if it fails.  The trace file showed that the connection was closed and the driver unloaded before the "EXECUTE IMMEDIATE :SQL_STR" was even attempted.  Of course without a valid connection the "EXECUTE IMMEDIATE :SQL_STR" will crash, but it is not its fault that the database connection was closed.

I'm wondering if the close cursor is, for some reason, disconnecting you from the database?  Do you check the for errors after the close cursor?



0
smatthesenAuthor Commented:
EAServer,

I have error check statements after the close cursor and they are not returning any errors.

I put a simple SQL statement after this (SELECT COUNT(*) INTO ...) and then a messagebox with the result.  It came back and expected and then the "EXECUTE IMMEDIATE :SQL_STR" caused the app to crash as it did before.  This really has me baffled.  

Any other ideas?
Is there some other way of dynamically running sql statements that don't return a result set?  (just in case it has something to do with the execute immediate)

thanks
0
EAServerCommented:
Then I'm kind of stumped as to what is causing the error.  It may be the ODBC driver, like I said it's never been all that stable.  ODBC is afterall a microsoft standard, and an old one that is becoming obsolete because of the new OLEDB standard.  Having a good ODBC driver is not a high priority of the OpenSource community.  That's why I'd recommend at least checking this with the JDBC driver which is a bit more reliable.

A work around for you situation would be to use a dynamic datastore something like...

string ls_sql
string ls_error
string ls_dwsyntax
long ll_rowcount
datastore lds_data

lds_data = create datastore

//Generate a dynamic select statement instead of a delete
ls_sql = "select customerid from barcodes where mbol in ('00401526640P') and customerid = 7"

//Use syntaxfromsql to get the datawindow object syntax
ls_dwsyntax = sqlca.SyntaxFromSQL(ls_sql, "", ls_error)

//Create the dataobject for the datastore from the syntax
lds_data.Create(ls_dwsyntax)
lds_data.SetTransObject(SQLCA)
ll_RowCount = lds_data.Retrieve()

//Delete all of the rows returned
lds_data.RowsMove(1, ll_RowCount, Primary!, lds_data, 1, Delete!)

//Update the datawindow, which will send delete sql to the database
lds_data.Update()


I have typed this code freehand, and it does not include any error checking.  You might need to debug it just a bit, and of course add the appropriate error checking, commits, and rollbacks, but the concept should work.  Not as neat as dynamic sql, but it should get the same results.


0
EAServerCommented:
Then I'm kind of stumped as to what is causing the error.  It may be the ODBC driver, like I said it's never been all that stable.  ODBC is afterall a microsoft standard, and an old one that is becoming obsolete because of the new OLEDB standard.  Having a good ODBC driver is not a high priority of the OpenSource community.  That's why I'd recommend at least checking this with the JDBC driver which is a bit more reliable.

A work around for you situation would be to use a dynamic datastore something like...

string ls_sql
string ls_error
string ls_dwsyntax
long ll_rowcount
datastore lds_data

lds_data = create datastore

//Generate a dynamic select statement instead of a delete
ls_sql = "select customerid from barcodes where mbol in ('00401526640P') and customerid = 7"

//Use syntaxfromsql to get the datawindow object syntax
ls_dwsyntax = sqlca.SyntaxFromSQL(ls_sql, "", ls_error)

//Create the dataobject for the datastore from the syntax
lds_data.Create(ls_dwsyntax)
lds_data.SetTransObject(SQLCA)
ll_RowCount = lds_data.Retrieve()

//Delete all of the rows returned
lds_data.RowsMove(1, ll_RowCount, Primary!, lds_data, 1, Delete!)

//Update the datawindow, which will send delete sql to the database
lds_data.Update()


I have typed this code freehand, and it does not include any error checking.  You might need to debug it just a bit, and of course add the appropriate error checking, commits, and rollbacks, but the concept should work.  Not as neat as dynamic sql, but it should get the same results.


0
smatthesenAuthor Commented:
Haven't had a chance to try your last example.  Is there a possibility that I could have something wrong with the tables in the database?  

Also, do I need PB Enterprise to use JDBC?  We only have Professional here.  If not, what is the best way to implement JBCD?

thanks for all of your help!
0
EAServerCommented:
Is there a possiblity, probably but chances are the table is fine.  You might try running some of the MySQL validation programs to make sure the internal database and its objects are not corrupted, but I don't think that is the cause here.


I'm not sure about JDBC in PB professional.  The feature matrix on the Sybase web site did not mention it.  If it is not an option on your DB profile window, then do a custom install of PB and see if it is an option there.  If not it must not be available in PB professional.
0
smatthesenAuthor Commented:
Haven't had a chance to try your last example.  Is there a possibility that I could have something wrong with the tables in the database?  

Also, do I need PB Enterprise to use JDBC?  We only have Professional here.  If not, what is the best way to implement JBCD?

thanks for all of your help!
0
buasuwanCommented:
just FYI.

Error 3 = No such process

but, who executed these commands? PB or ODBC?

(6143c40): CANCEL: (0 MilliSeconds)
(6143c40): DISCONNECT: (0 MilliSeconds)
(6143c40): SHUTDOWN DATABASE INTERFACE: (0 MilliSeconds)


0
smatthesenAuthor Commented:
Not sure, all I know is that there is no cancel or disconnect command in these sections of code.  
I am out of ideas here.
This is what I've done so far:
(1) PB upgrade from 8.0.1 to 8.0.3
(2) MyODBC driver upgrade from 2.50 to 3.51
(3) Tried (not currently using though) MySQL 4.01 instead of 3.23
(4) Put simple SQL statement between last SQL and the one that is app crashes on.  
    Result:  new SQL worked fine, still crashed at the same spot.  
    Note:  I still received the CANCEL, DISCONNECT, and SHUTDOWN DATABASE INTERFACE at the same spot.  However, the new SQL statement processed fine.  The app then crashed at the same spot it had been, but without getting the CANCEL, DISCONNECT, SHUTDOWN DATABASE INTERFACE commands in the trace log at that point.
(5) Tried different ways of reworking my dynamic sql commands in an attempt to prevent the error.  Even went so far as to copy the command out of the trace log and put it in as a static command and it still crashed.  


I think I may have found a link.  The commands I'm dealing with all are manipulating my barcodes table.  I have rebuilt the database a couple times now and it doesn't seem to help any.

Any more ideas?
0
smatthesenAuthor Commented:
Alright guys.  Didn't really find a cause to this.  
Managed to work things around where I execute these SQL statements a different way.  
Still not understanding why this worked for so long and then all of a sudden started having this problem.
I'm sure it has something to do with MySQL and the ODBC driver, but I couldn't find a combination that worked.

Will give you guys the points for helping even we never were really able to fix the problem.

Thanks,
Scott
0
smatthesenAuthor Commented:
Thanks for your help!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Editors IDEs

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.