What could be causing the PhoneGap Android app to crash when large amounts of data are being inserted into SQL?

Question

What could be causing the PhoneGap Android app to crash when large amounts of data are being inserted into SQL?

I am currently experiencing an issue with my PhoneGap app on Android. Upon startup, the app inserts around 500 rows into an SQL database with a table containing 10 columns. Although this doesn't seem like a large amount of data, I have encountered crashes when working with the SQL database on certain versions of Android (1.6, 2.1, some 2.3.) The JSON file that I use to populate the DB is about 120 kB in size and resides within a text file. The code snippet I utilize for populating the database is causing the crash on Android 1.6:

db = window.openDatabase("db", "1.0", "Description", 1000000); 
$.get('db/app_data.dat',function(result){
  var data = $.parseJSON(result);
  try {
    db.transaction(function(tx){
      $.each(data.items, function(i, v){
        try {
          tx.executeSql('INSERT INTO table(c1,c2,c3, ...) VALUES (?,?,?, ...)',[v.c1, v.c2, v.c3, ...]);
        } catch(e) {
          alert(e.message);
        }
      });
    });
  } catch(e) {
    alert(e.message);
    return;
  }
});

I would appreciate any assistance or insights as to why this might be happening. Could there be some unanticipated limitations or bugs in Android that I'm unaware of?

EDIT:

Upon reviewing the LogCat output provided below, it seems that there are warnings related to JNI local reference tables overflowing. Unfortunately, my knowledge of Java and Android is limited, so any guidance on resolving this issue would be greatly appreciated.

...

javascript android sql crash cordova

Answer 1

Answer №1

In the response from Phobos, there is valuable information provided; however, it does not specifically address how it can be applied to resolve your particular issue. I encountered a similar problem during my performance testing in Android using JavaScript that communicates with Java through an object bound in the webview context via addJavascriptInterface. Even though JNI is not explicitly utilized, it seems that the bound interface utilizes JNI internally to transfer data - resulting in errors and stack traces like the ones you have experienced. Evidently, operations such as webDB or localStorage also leverage JNI in their functioning.

According to the insights shared by Phobos, there exists a limitation on the number of references permissible when working with JNI. For JavaScript indirectly utilizing JNI, these references must be maintained based on the scope of the JavaScript functions. After examining your code, determining precisely where the limit is exceeded remains unclear. It might possibly be due to either the total number of transaction calls being made or the arrays of values ending up surpassing 512 elements. If preserving transactional integrity is essential and you have over 500 operations, finding a workaround could be challenging. Nevertheless, adjusting your code to construct a query string externally to the tx.executeSql call may help bypass the 512 limit.

An alternative approach could involve rewriting the code to assemble query strings beforehand and then executing tx.executeSql within an anonymous function wrapper. Instead of relying on the syntax

'INSERT INTO table() VALUES()',[]

, consider building strings containing the values themselves. Although dealing with more than 500 transactions in one go could still present challenges, attempting this adjustment could potentially yield positive outcomes!

P.S. Here's a piece of code that was causing crashes for me and the solution implemented:

var test = function() {
    var a = "a";
    for(i=0;i<1000;i++) {
        boundJavaObj.test(a);
    }
}

The execution of test() resulted in an error message like:

03-28 10:57:45.634: W/dalvikvm(21294): ReferenceTable overflow (max=512)

var test2 = function() {
    var a = "a";
    for(i=0;i<1000;i++) {
        (function(){boundJavaObj.test(a);})();
    }
}

Executing test2() did not lead to any crashes.

Answer 2

In the response from Phobos, there is valuable information provided; however, it does not specifically address how it can be applied to resolve your particular issue. I encountered a similar problem during my performance testing in Android using JavaScript that communicates with Java through an object bound in the webview context via addJavascriptInterface. Even though JNI is not explicitly utilized, it seems that the bound interface utilizes JNI internally to transfer data - resulting in errors and stack traces like the ones you have experienced. Evidently, operations such as webDB or localStorage also leverage JNI in their functioning.

According to the insights shared by Phobos, there exists a limitation on the number of references permissible when working with JNI. For JavaScript indirectly utilizing JNI, these references must be maintained based on the scope of the JavaScript functions. After examining your code, determining precisely where the limit is exceeded remains unclear. It might possibly be due to either the total number of transaction calls being made or the arrays of values ending up surpassing 512 elements. If preserving transactional integrity is essential and you have over 500 operations, finding a workaround could be challenging. Nevertheless, adjusting your code to construct a query string externally to the tx.executeSql call may help bypass the 512 limit.

An alternative approach could involve rewriting the code to assemble query strings beforehand and then executing tx.executeSql within an anonymous function wrapper. Instead of relying on the syntax

'INSERT INTO table() VALUES()',[]

, consider building strings containing the values themselves. Although dealing with more than 500 transactions in one go could still present challenges, attempting this adjustment could potentially yield positive outcomes!

P.S. Here's a piece of code that was causing crashes for me and the solution implemented:

var test = function() {
    var a = "a";
    for(i=0;i<1000;i++) {
        boundJavaObj.test(a);
    }
}

The execution of test() resulted in an error message like:

03-28 10:57:45.634: W/dalvikvm(21294): ReferenceTable overflow (max=512)

var test2 = function() {
    var a = "a";
    for(i=0;i<1000;i++) {
        (function(){boundJavaObj.test(a);})();
    }
}

Executing test2() did not lead to any crashes.

Answer 3

Answer №2

Perhaps a recursive callback approach could be the solution:

//consider using a recursive function like this
var sqlStatements = ["INSERT INTO ...", .. .. .. , "INSERT INTO ..."];

function processStatements() {
    db.transaction(function(tx) {
        if (sqlStatements.length > 0) {
            var sql = sqlStatements.shift();
            tx.executeSql(sql);
        } else {
            alert('Finished processing');
        }
        return true;
    }, function(tx, err) { 
        console.log("SQL Error: " + err); 
    }, processStatements);
};

processStatements();

Answer 4

Perhaps a recursive callback approach could be the solution:

//consider using a recursive function like this
var sqlStatements = ["INSERT INTO ...", .. .. .. , "INSERT INTO ..."];

function processStatements() {
    db.transaction(function(tx) {
        if (sqlStatements.length > 0) {
            var sql = sqlStatements.shift();
            tx.executeSql(sql);
        } else {
            alert('Finished processing');
        }
        return true;
    }, function(tx, err) { 
        console.log("SQL Error: " + err); 
    }, processStatements);
};

processStatements();

Answer 5

Answer №3

Alright, I've discovered the solution. The limit is 512 local references. To resolve this issue, you should either convert them to global references using NewGlobalRef(), or delete the locals shortly after creating them if they're no longer needed. However, be aware that changing them to global references will result in memory leakage.

For further information on this known issue, please refer to this thread.

Answer 6

Alright, I've discovered the solution. The limit is 512 local references. To resolve this issue, you should either convert them to global references using NewGlobalRef(), or delete the locals shortly after creating them if they're no longer needed. However, be aware that changing them to global references will result in memory leakage.

For further information on this known issue, please refer to this thread.

What could be causing the PhoneGap Android app to crash when large amounts of data are being inserted into SQL?

Answer №1

Answer №2

Answer №3

Similar questions

Sending data from PHP to a text file upon clicking a button

Exploring the functionalities of class methods within an Angular export function

Pressing the middle of the screen to access the Camera App on an Android device

How can the Header of a get-request for an npm module be modified?

How can we activate navigation on a mobile browser?

Acquiring HTML Element Data with Clojure

The task execution in Android Studio failed due to an exception with the unknown idk-1.8

Does the layout.tsx file in Next JS only affect the home page, or does it impact all other pages as well?

Guide to linking 2 tables in Hibernate within a POJO class structure

Leveraging ng-hide in Angular to show or hide elements based on the state

Creating a dynamic content space: A step-by-step guide

Exploring AngularJS Scope Feeds through Looping

Optimal data format for a flexible DataGridView

How can UI tests be run in headless mode in Selenium 4 and above?

Passing data between API tests in JavaScript

Prioritize displaying a group of data before organizing the remaining information by a selected column

Pattern matching for identifying repeated numeric sequences

Is there a way to display a cradled FAB in a bottom app bar exclusively for one specific fragment?

Tips for handling the accent mark (diacritic mark)

Having trouble reaching an injected dependency beyond the controller method