We Keep Coding

How to know from which activity an error comes from my application in production?

My application is 2 months in production and I was checking the section that shows the play console crashing and I have been able to solve some problems, but there are some in which I do not know exactly what activity they come from, mi error is java.lang.IllegalStateException and when I press see more:
java.lang.IllegalStateException:
at androidx.work.impl.utils.ForceStopRunnable.run (ForceStopRunnable.java:115)
at androidx.work.impl.utils.SerialExecutor$Task.run (SerialExecutor.java:91)
at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:641)
at java.lang.Thread.run (Thread.java:919)
Caused by: android.database.sqlite.SQLiteCantOpenDatabaseException:
at android.database.sqlite.SQLiteConnection.nativeOpen (Native Method)
at android.database.sqlite.SQLiteConnection.open (SQLiteConnection.java:300)
at android.database.sqlite.SQLiteConnection.open (SQLiteConnection.java:218)
at android.database.sqlite.SQLiteConnectionPool.openConnectionLocked (SQLiteConnectionPool.java:737)
at android.database.sqlite.SQLiteConnectionPool.open (SQLiteConnectionPool.java:284)
at android.database.sqlite.SQLiteConnectionPool.open (SQLiteConnectionPool.java:251)
at android.database.sqlite.SQLiteDatabase.openInner (SQLiteDatabase.java:1386)
at android.database.sqlite.SQLiteDatabase.open (SQLiteDatabase.java:1331)
at android.database.sqlite.SQLiteDatabase.openDatabase (SQLiteDatabase.java:967)
at android.database.sqlite.SQLiteDatabase.openDatabase (SQLiteDatabase.java:955)
at android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked (SQLiteOpenHelper.java:448)
at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase (SQLiteOpenHelper.java:391)
at androidx.sqlite.db.framework.FrameworkSQLiteOpenHelper$OpenHelper.getWritableSupportDatabase (FrameworkSQLiteOpenHelper.java:145)
at androidx.sqlite.db.framework.FrameworkSQLiteOpenHelper.getWritableDatabase (FrameworkSQLiteOpenHelper.java:106)
at androidx.room.RoomDatabase.beginTransaction (RoomDatabase.java:352)
at androidx.work.impl.utils.ForceStopRunnable.cleanUp (ForceStopRunnable.java:156)
at androidx.work.impl.utils.ForceStopRunnable.run (ForceStopRunnable.java:87)
Out of 750 users who have installed my application it happened to one 5 times, Should a bug that happened to a single user (of 750) be investigated or not?, And most importantly, how can I know exactly where the error came from?

When throwing an exception, put the user that is currently being accessed so you can track it down. Put as much info in the exception as possible that will help you figure out which item might be causing it.
https://stackify.com/best-practices-exceptions-java/
These are some good examples as well as good practices to follow. In those messages that are mentioned, add the user id or something that helps you identify what's going on. Learn to make custom exceptions and catch the most specific exceptions you can. Don't just catch Exception, its better to be specific about the exception your catching rather than casting a wide net.

Again ERROR java.util.concurrent.TimeoutException: android.view.ThreadedRenderer.finalize() timed out after 10 seconds

Please don't mark as duplicate
I get this error very often on crashlytics, and I can't find the problem. I saw it here or here but I don't have any WebViews in my app.
I have in my app some AsyncTasks that are processing some date: select from DB, compare and call the listener to update UI when is done (I check if activity is still visible when it's needed to update UI). This processing can be long if user has 10k records to compare.
Have to mention that error happens for different devices manufacturers (more on Samsung) and on different Android versions (more on Andorid 6.0 +)
I get this error many times as different one, for example:
File: Daemons.java:217
java.util.concurrent.TimeoutException: android.view.ThreadedRenderer.finalize() timed out after 10 seconds
1 at android.view.ThreadedRenderer.nDeleteProxy(Native Method)
2 at android.view.ThreadedRenderer.finalize(ThreadedRenderer.java:459)
3 at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:217)
4 at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:200)
5 at java.lang.Thread.run(Thread.java:818)
File: Daemons.java:206
java.util.concurrent.TimeoutException: android.view.ThreadedRenderer.finalize() timed out after 10 seconds
1 at android.view.ThreadedRenderer.nDeleteProxy(Native Method)
2 at android.view.ThreadedRenderer.finalize(ThreadedRenderer.java:449)
3 at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:206)
4 at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:189)
5 at java.lang.Thread.run(Thread.java:818)
File Daemons.java:210
java.util.concurrent.TimeoutException: android.view.ThreadedRenderer.finalize() timed out after 15 seconds
1 at android.view.ThreadedRenderer.nDeleteProxy(Native Method)
2 at android.view.ThreadedRenderer.finalize(ThreadedRenderer.java:427)
3 at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:210)
4 at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:193)
5 at java.lang.Thread.run(Thread.java:818)
etc...

As one of the posts you link to describes, this is an exception being generated by garbage collection taking too long for an object with a native code implementation. I ran into this exception and found a solution by looking at the source code producing this exception java.lang.Daemons$FinalizerDaemon.finalizerTimedOut() which you can see here.
In finalizerTimedOut(), if Thread.getDefaultUncaughtExceptionHandler() == null, it create and logs a TimeoutException() and exits with a non-zero code (System.exit(2);)! To the user, this will look like an FC! To prevent this, you need to call Thread.setDefaultUncaughtExceptionHandler() to catch and handle this exception.

TynyVM exception working with legOS

so I'm working with legOS (the little legos robots) and basically what I'm doing is finding a solution to a maze with A* and I wanna use that to tell the robot where to move around the maze.
But the problem that I've been having is that when I try to initiate the priotiry queue it gives me this exception
js.tinyvm.TinyVMException: Invalid byte tag in constant pool: 15
at js.tinyvm.ClassRecord.getClassRecord(ClassRecord.java:871)
at js.tinyvm.ClassRecord.storeReferredClasses(ClassRecord.java:394)
at js.tinyvm.Binary.processClasses(Binary.java:381)
at js.tinyvm.Binary.createFromClosureOf(Binary.java:309)
at js.tinyvm.TinyVMTool.link(TinyVMTool.java:97)
at js.tinyvm.TinyVMTool.link(TinyVMTool.java:48)
at lejos.pc.tools.NXJLink.start(NXJLink.java:134)
at lejos.pc.tools.NXJLink.run(NXJLink.java:101)
at lejos.pc.tools.NXJLink.start(NXJLink.java:33)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at lejos.pc.tools.ToolStarter.startTool(ToolStarter.java:31)
at lejos.pc.tools.NXJLink.main(NXJLink.java:28)
Caused by: org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in constant pool: 15
at org.apache.bcel.classfile.Constant.readConstant(Constant.java:146)
at org.apache.bcel.classfile.ConstantPool.<init>(ConstantPool.java:67)
at org.apache.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:222)
at org.apache.bcel.classfile.ClassParser.parse(ClassParser.java:136)
at js.tinyvm.ClassRecord.getClassRecord(ClassRecord.java:865)
... 14 more
Linking the file failed with exit status 1
I know is with the priority queues because I've commented those lines and the program links successfully
here's where I start the queues
PriorityQueue<State> frontier;
frontier = new PriorityQueue<State>(new CostComparator());
PriorityQueue<State> visited;
visited = new PriorityQueue<State>(new CostComparator());
Can someone tell me why this happens?
I'm using everything in 32-bit env and nothing works..

Hope this helps for future reference, the runtime library for lejOS does not support Priority queue class, only queue so I had to implement my own queue with this library.

Problem getting Java Streams in HP Tandem (Non-Stop)

We are porting a simple Java application between Tandem NonStop systems, from G-Series to H-Series. Java version is 1.5.0_02.
When performing basic I/O tasks like getting output stream from or opening a client socket, we receive exceptions like
java.io.IOException: Value out of range
or
java.net.SocketException: Value out of range
("value out of range" is Tandem native jargon for, well, quite everything I suppose).
Has anybody got similar issues? i.e. I/O corruption while for example messing with JNI?
I suppose there is something wrong with the system, but where might it be?
Thank you.
EDIT:
adding snippets as requested
sample snippet (a) - using Runtime.exec () (adapted)
Properties envVars = new Properties();
Process p = r.exec("/bin/env");
envVars.load(p.getInputStream());
Stack trace (a):
java.io.IOException: Value out of range (errno:4034)
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:194)
at java.lang.UNIXProcess$DeferredCloseInputStream.read(UNIXProcess.java:221)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:254)
at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411)
at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at java.io.BufferedReader.fill(BufferedReader.java:136)
at java.io.BufferedReader.readLine(BufferedReader.java:299)
at java.io.BufferedReader.readLine(BufferedReader.java:362)
at util.Environment.getVariables(Environment.java:39)
Last line fails, and output gets redirected to console (!).
sample snippet (b) - using HttpURLConnection:
public WorkerThread (HttpURLConnection conn, String requestData, Logger logger)
{
this.conn = conn;
...
}
public void run ()
{
OutputStream out = conn.getOutputStream ();
}
Stack trace (b):
java.net.SocketException: Value out of range (errno:4034)
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.Socket.connect(Socket.java:507)
at sun.net.NetworkClient.doConnect(NetworkClient.java:155)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:365)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:477)
at sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:280)
at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:337)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:176)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:736)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:162)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:828)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230)
Case (a) can be avoided because it was a workaround for other issues with previous JRE version (!), but same behaviour with sockets is really nasty.

Error code 4034 seem to indicate that a specific server is not running in your NonStop cluster. Are you sure that your system is setup properly?

Update: The problem was caused by a spurious .so library.

SQL Server / JDBC Connectivity Issues

I am experiencing some strange behaviour in my Java server application whereby database operations that usually take a few milliseconds are sporadically taking much longer (30s - 170s) to complete. This isn't isolated to a specific query as I've seen the delays occurring for both SQL update and select statements. Also, all of my select statements use the NOLOCK option so I've ruled out possible lock contention.
The last time I saw a delay I managed to capture the following stack trace from JConsole; the update in question typically takes 5ms to complete but this stack trace was accessible for at least 10 - 20 seconds. The trace suggests to me that the statement has been executed but there is some delay in retrieving the result although I could be wrong? Obviously as this was an update statement the only result I'd expect would be the row count (i.e. not a large result set of data).
I saw a "transport level error" in SQL Server Management Studio at around the time of the delay.
One suggestion I've had is that these problems are due to SQL Server resources being exhausted. Has anyone seen anything similar? Can anyone shed any light on this problem?
Thanks in advance.
Stack Trace:
Name: MessageRouterImplThread-2
State: RUNNABLE
Total blocked: 0 Total waited: 224
Stack trace:
java.net.SocketInputStream.socketRead0(Native Method)
java.net.SocketInputStream.read(SocketInputStream.java:129)
com.microsoft.util.UtilSocketDataProvider.getArrayOfBytes(Unknown Source)
com.microsoft.util.UtilBufferedDataProvider.cacheNextBlock(Unknown Source)
com.microsoft.util.UtilBufferedDataProvider.getArrayOfBytes(Unknown Source)
com.microsoft.jdbc.sqlserver.SQLServerDepacketizingDataProvider.signalStartOfPacket(Unknown Source)
com.microsoft.util.UtilDepacketizingDataProvider.getByte(Unknown Source)
com.microsoft.util.UtilByteOrderedDataReader.readInt8(Unknown Source)
com.microsoft.jdbc.sqlserver.tds.TDSRequest.getTokenType(Unknown Source)
com.microsoft.jdbc.sqlserver.tds.TDSRequest.processReply(Unknown Source)
com.microsoft.jdbc.sqlserver.SQLServerImplStatement.getNextResultType(Unknown Source)
com.microsoft.jdbc.base.BaseStatement.commonTransitionToState(Unknown Source)
com.microsoft.jdbc.base.BaseStatement.postImplExecute(Unknown Source)
com.microsoft.jdbc.base.BasePreparedStatement.postImplExecute(Unknown Source)
com.microsoft.jdbc.base.BaseStatement.commonExecute(Unknown Source)
com.microsoft.jdbc.base.BaseStatement.executeUpdateInternal(Unknown Source)
com.microsoft.jdbc.base.BasePreparedStatement.executeUpdate(Unknown Source)
- locked com.microsoft.jdbc.sqlserver.SQLServerConnection#c4b83f
org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:101)
org.springframework.jdbc.core.JdbcTemplate$2.doInPreparedStatement(JdbcTemplate.java:798)
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:591)
org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:792)
org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:850)
org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:858)
org.springframework.jdbc.core.simple.SimpleJdbcTemplate.update(SimpleJdbcTemplate.java:237)

"...whereby database operations that
usually take a few milliseconds are
sporadically taking much longer (30s -
170s) to complete."
What you are describing sounds like an incorrectly cached query plan, due to out of date statistics (and/or indexes that need rebuilding), or incorrect parameter sniffing. The timeout could be occuring because the server is taking longer than the default connection timeout.
I would talk to your DBA and first get statistics updated, and if that doesn't work get the indexes of the tables involved in the query rebuilt.
Run this on your Database (with the usual caveat about not runninhg in Production without talking to your admin/DBA, and run at own risk etc.):
EXEC sp_updatestats
EXEC sp_refreshview
EXEC sp_msForEachTable 'EXEC sp_recompile ''?'''
Alternatively, you mention time of day being a factor. Could it be that a backup or scheduled job is occuring at that time?
Update: You could kick off a profiler trace: MS SQL Server 2008 - How Can I Log and Find the Most Expensive Queries? but don't restrict to your DB. Such a trace, as long as it is started from SSMS as per that post, is relatively low impact (3-5% ish).

The "transport level error" seems to indicate connectivity problems. Is the database on a separate machine?