App keeps stopping after setup wizard

[csam23]

Hello,

I have built and downloaded the serval mesh app through wifi and through usb connection. Both result in the app closing once I bypass the setup wizard window where I input the name and phone number. In the Logcat of Android studio, these two errors show once the app closes:

09-16 18:49:11.894 19038-19066/org.servalproject E/WifiApControl: Profile saved_user_ap has no SSID!
09-16 18:49:11.935 19038-19066/org.servalproject A/libc: ~/batphone/app/src/main/jni/serval-dna/rhizome_database.c:312: int rhizome_opendb(): assertion "!sqlite3_temp_directory" failed

Thanks in advance!

[lakeman]

Odd, sqlite3.c seems to define that variable twice. Try;

- SQLITE_API char *sqlite3_temp_directory;
+ SQLITE_API char *sqlite3_temp_directory = 0;

[csam23]

Thank you for the quick response!
My build command is now failing with the above code in sqlite3.c
error: redefinition of 'sqlite3_temp_directory'
SQLITE_API char *sqlite3_temp_directory = 0;

For my info, when I originally cloned batphone, the build command was failing due to the libsodium.a not existing issue that was solved in #127

Android NDK: ERROR:~/batphone/app/src/main/jni/opus/Android.mk:sodium: LOCAL_SRC_FILES points to a missing file
Android NDK: Check that ~/batphone/app/src/main/jni/libsodium/libsodium-android-armv7-a/lib/libsodium.a exists or that its path is correct

However, my ndk and sdk versions are the most recent released. I think I just created libsodium.a from command terminal with gradle command which caused the build command to work.

[lakeman]

Yeah I thought it was odd that the variable was defined twice. I'd suggest removing the second definition too. No idea why this has never failed for me.

[csam23]

I commented out the second definition. Build works and reinstalled onto phone. But app still stops when main menu comes up.

[lakeman]

rhizome_database is a thread local value, but sqlite3_temp_directory is not. Is there something about the way you are using / have changed the application that might cause the database to be opened in multiple threads?

[lakeman]

We should probably change rhizome_opendb to only set the sqlite temp folder if it has never been set, then remove the cleanup code when the database is closed.

[csam23]

Building the libsodium.a file from the command terminal is the only change I've made to the application thus far.

Okay, that sounds like a plan. I'm still new to the code though for implementing those changes.

[284921310]

To All:
I have the same problem with this project.can anyone give me some suggest??
first of all,I meet the "libsodium.a exists or that its path is correct" problem, so I build the libsodium's sh script in terminal windows,then build is OK, but running the apk have another problem,the problem is " int rhizome_opendb(): assertion "!sqlite3_temp_directory" failed"
Now, I have no idea to deal with this problem,please give me some suggest. thx very much!

[284921310]

@csam23 do you solve the problem?can you give me the method?thank you!

[284921310]

by the way,my envirment is
1、vmware with ubuntu 14.04
2、NDK 18.1.5063045
3、gradle 4.4-all

[lakeman]

Something like;

https://github.com/servalproject/serval-dna/blob/development/rhizome_database.c#L311

-  assert(!sqlite3_temp_directory);
+  if(!sqlite3_temp_directory)

https://github.com/servalproject/serval-dna/blob/development/rhizome_database.c#L488

-    assert(sqlite3_temp_directory);
-    sqlite3_free(sqlite3_temp_directory);
-    sqlite3_temp_directory = NULL;

Though this is deliberately creating a tiny memory leak.

[284921310]

@lakeman thx a lot.now the project can be running, but i can't see the tiny memory leak's effect,maybe a lot of test can help me.

[lakeman]

I said tiny, since the backend daemon will allocate a single string and never release it when it quits gracefully. When the backend is running within batphone, the daemon never quits.

I only mentioned it as the memory allocation will show up if anyone runs the daemon within valgrind or other automated tools that check for memory leaks.

[lakeman]

Before I push a proper fix, I'll need to work out when to release that memory, since I sometimes run all of our automated tests using clang's memory leak detection. The false positives would annoy me...