09-27 09:47:08.610982 2758 2758 F DEBUG : ip cf52df60 sp c877ee10 lr cf50539d pc c9691be2 cpsr 60000030
09-27 09:47:08.619907 2758 2758 F DEBUG :
09-27 09:47:08.619907 2758 2758 F DEBUG : backtrace:
09-27 09:47:08.620160 2758 2758 F DEBUG : #00 pc 0050cbe2 /data/app/com.ratta.supernote.note-PaOg00oJE0Oa4RrX_U201A==/base.apk (offset 0x1f13000)
09-27 09:47:08.620283 2758 2758 F DEBUG : #01 pc 0050e123 /data/app/com.ratta.supernote.note-PaOg00oJE0Oa4RrX_U201A==/base.apk (offset 0x1f13000)
09-27 09:47:08.620384 2758 2758 F DEBUG : #02 pc 005f43ab /data/app/com.ratta.supernote.note-PaOg00oJE0Oa4RrX_U201A==/base.apk (offset 0x1f13000)
09-27 09:47:08.620505 2758 2758 F DEBUG : #03 pc 00078d8d /data/app/com.ratta.supernote.note-PaOg00oJE0Oa4RrX_U201A==/oat/arm/base.odex (offset 0x72000)
Best Answer
O
Olivier @MyScript
said
about 2 years ago
Dear Hedy,
after doing further investigation internally, we have 2 following questions:
-Do you have 2 separate editors? (can you check in debug mode both editors have different references?)
-Do you have 2 different renderers (e.g. a renderer with a null render target in batch mode, and a "standard" renderer in incremental)?
Indeed, it is likely that you have either an editor or renderer shared in between both threads, and one thread is likely to destroy the object while still used by the other.
Can you please check this? Otherwise, can you please provide us with full project that allows to reproduce?
Also, we are questioning the reason you are using 2 thread, as this is battery and CPU consuming.
First, when you say the crash occurs at editor.penup(), do you mean editor.pointerUp(...)? Indeed, we do not have a penup function but only pointerUp.
Currently, the below log doesn't help much, as a "null pointer dereference" can have many causes: -First, what is the frequency of the crash? Is it occuring on a specific release of the Android? -Can you confirm the language resources are aligned with the release of the iink SDK? E.g. are you using the iink SDK 2.0 with the corresponding 2.0 language resources? Using the resources from the 2.0 release with the iink SDK 1.5 could indeed cause such issue. -Do you have a scenario that allows to reproduce? If so, could we have it? -Ideally, would you have a project that allows to reproduce? -If you can reproduce, could we have a log file? This can be done setting the "debug.log-file" configuration (of course, replace PATH with the directory where you want to store your log file): engine.getConfiguration().setString("debug.log-file", "PATH/iink.log");
Best regards,
Olivier
H
Hedy Jiang
said
about 2 years ago
Thanks!
First, when you say the crash occurs at editor.penup(), do you mean editor.pointerUp(...)? Indeed, we do not have a penup function but only pointerUp. editor.pointerUp(...). Currently, the below log doesn't help much, as a "null pointer dereference" can have many causes: -First, what is the frequency of the crash? Is it occuring on a specific release of the Android?
This is not sure, our development environment is only Android 8.1.
-Can you confirm the language resources are aligned with the release of the iink SDK? E.g. are you using the iink SDK 2.0 with the corresponding 2.0 language resources? Using the resources from the 2.0 release with the iink SDK 1.5 could indeed cause such issue.
Both language and sdk are 2.0
-Do you have a scenario that allows to reproduce? If so, could we have it? -Ideally, would you have a project that allows to reproduce? -If you can reproduce, could we have a log file? This can be done setting the "debug.log-file" configuration (of course, replace PATH with the directory where you want to store your log file): engine.getConfiguration().setString("debug.log-file", "PATH/iink.log");
I can add a log according to your instructions, reproduce it again, I will send it to you
O
Olivier @MyScript
said
about 2 years ago
Dear Hedy,
thank you for the update.
Using Android 8.1 is not likely to cause any issue, we have daily tests running on the latter.
When you have a log a scenario to reproduce, please let us know.
Best regards,
Olivier
H
Hedy Jiang
said
about 2 years ago
Hi Olivier @MyScript,
I have this problem again, the log is linked below. I found it most likely to happen in a scenario like this:
1. Create an editor, package, part in thread one; pass in data for batch identification.
2. Create an editor, package, part in another thread; then use incremental identification.
So I wonder if there will be a problem with two editors working at the same time
O
Olivier @MyScript
said
about 2 years ago
Dear Hedy,
thank you for the update and log.
We will investigate and keep you updated.
Best regards,
Olivier
O
Olivier @MyScript
said
about 2 years ago
Dear Hedy,
we investigated both the iink log and the logcat, but unfortunately these do not help much:
-The iink log doesn't contain the crash information
-Regarding the logcat, it doesn't indicate an error on the iink side, but only on the native side. We would need a complete logcat with all the iink calls.
Can we have the full logcat? Also, would you have a project that would allow us to reproduce? It would help understand how you deal with threads.
Thank you,
Best regards,
Olivier
H
Hedy Jiang
said
about 2 years ago
I found the reason for the crash, the way to reproduce is simple:
1. Create an engine
2. Create and open two packages. package1,package2
3. Create and open two Parts. part1,part2
4. Create two Editors: editor1, editor2
5.Editor binds part1 and part2 respectively
6. The editor1 performs batch identification, and executes part1.close() and editor1.close() after the identification is completed;
7. When editor2 does incremental identification, it will crash when editor1.pointerDown(...) is executed.
Summary: The reason for the crash is because of ediotr1.close(), if the close is not performed, the fifth step performing incremental recognition will not crash.
Doubt: Why does the shutdown of editor1 affect the recognition operation of editor2?
O
Olivier @MyScript
said
about 2 years ago
Dear Hedy,
thank you for the update.
Honestly, the scenario is not clear to me.
At point 7, you say "When editor2 does incremental identification, it will crash when editor1.pointerDown(...) is executed"
And in the summary: "The reason for the crash is because of ediotr1.close(),"
Is it the editor1.pointerDown or the editor1.close() that causes the crash?
Also, do you have an exception that is raised?
Thank you,
Olivier
O
Olivier @MyScript
said
about 2 years ago
Dear Hedy,
Currently, I was able to reproduce the crash.
We keep you updated.
Best regards,
Olivier
O
Olivier @MyScript
said
about 2 years ago
Answer
Dear Hedy,
after doing further investigation internally, we have 2 following questions:
-Do you have 2 separate editors? (can you check in debug mode both editors have different references?)
-Do you have 2 different renderers (e.g. a renderer with a null render target in batch mode, and a "standard" renderer in incremental)?
Indeed, it is likely that you have either an editor or renderer shared in between both threads, and one thread is likely to destroy the object while still used by the other.
Can you please check this? Otherwise, can you please provide us with full project that allows to reproduce?
Also, we are questioning the reason you are using 2 thread, as this is battery and CPU consuming.
Hedy Jiang
Appear in editor.penup(),it is a probabilistic event。The crash log is as follows:
09-27 09:47:08.441956 2455 2483 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 2483 (Thread-3), pid 2455 (.supernote.note)
09-27 09:47:08.609696 2758 2758 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
09-27 09:47:08.610120 2758 2758 F DEBUG : Build fingerprint: 'Android/htfy_px30:/Chauvet.D002.2209261001.742_root_:userdebug'
09-27 09:47:08.610257 2758 2758 F DEBUG : Revision: '0'
09-27 09:47:08.610384 2758 2758 F DEBUG : ABI: 'arm'
09-27 09:47:08.610463 2758 2758 F DEBUG : pid: 2455, tid: 2483, name: Thread-3 >>> com.ratta.supernote.note <<<
09-27 09:47:08.610598 2758 2758 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x8
09-27 09:47:08.610670 2758 2758 F DEBUG : Cause: null pointer dereference
09-27 09:47:08.610840 2758 2758 F DEBUG : r0 00000000 r1 00000005 r2 00000004 r3 00000000
09-27 09:47:08.610896 2758 2758 F DEBUG : r4 cb6886b0 r5 e83fdfa0 r6 00000183 r7 c877eec8
09-27 09:47:08.610937 2758 2758 F DEBUG : r8 7ca05f19 r9 41d80000 sl ffffffff fp 00000000
09-27 09:47:08.610982 2758 2758 F DEBUG : ip cf52df60 sp c877ee10 lr cf50539d pc c9691be2 cpsr 60000030
09-27 09:47:08.619907 2758 2758 F DEBUG :
09-27 09:47:08.619907 2758 2758 F DEBUG : backtrace:
09-27 09:47:08.620160 2758 2758 F DEBUG : #00 pc 0050cbe2 /data/app/com.ratta.supernote.note-PaOg00oJE0Oa4RrX_U201A==/base.apk (offset 0x1f13000)
09-27 09:47:08.620283 2758 2758 F DEBUG : #01 pc 0050e123 /data/app/com.ratta.supernote.note-PaOg00oJE0Oa4RrX_U201A==/base.apk (offset 0x1f13000)
09-27 09:47:08.620384 2758 2758 F DEBUG : #02 pc 005f43ab /data/app/com.ratta.supernote.note-PaOg00oJE0Oa4RrX_U201A==/base.apk (offset 0x1f13000)
09-27 09:47:08.620505 2758 2758 F DEBUG : #03 pc 00078d8d /data/app/com.ratta.supernote.note-PaOg00oJE0Oa4RrX_U201A==/oat/arm/base.odex (offset 0x72000)
Dear Hedy,
after doing further investigation internally, we have 2 following questions:
-Do you have 2 separate editors? (can you check in debug mode both editors have different references?)
-Do you have 2 different renderers (e.g. a renderer with a null render target in batch mode, and a "standard" renderer in incremental)?
Indeed, it is likely that you have either an editor or renderer shared in between both threads, and one thread is likely to destroy the object while still used by the other.
Can you please check this? Otherwise, can you please provide us with full project that allows to reproduce?
Also, we are questioning the reason you are using 2 thread, as this is battery and CPU consuming.
Thank you,
Best regards,
Olivier
- Oldest First
- Popular
- Newest First
Sorted by Oldest FirstOlivier @MyScript
Dear Hedy,
thank you for contacting us.
First, when you say the crash occurs at editor.penup(), do you mean editor.pointerUp(...)? Indeed, we do not have a penup function but only pointerUp.
Currently, the below log doesn't help much, as a "null pointer dereference" can have many causes:
-First, what is the frequency of the crash? Is it occuring on a specific release of the Android?
-Can you confirm the language resources are aligned with the release of the iink SDK? E.g. are you using the iink SDK 2.0 with the corresponding 2.0 language resources? Using the resources from the 2.0 release with the iink SDK 1.5 could indeed cause such issue.
-Do you have a scenario that allows to reproduce? If so, could we have it?
-Ideally, would you have a project that allows to reproduce?
-If you can reproduce, could we have a log file? This can be done setting the "debug.log-file" configuration (of course, replace PATH with the directory where you want to store your log file): engine.getConfiguration().setString("debug.log-file", "PATH/iink.log");
Best regards,
Olivier
Hedy Jiang
Thanks!
First, when you say the crash occurs at editor.penup(), do you mean editor.pointerUp(...)? Indeed, we do not have a penup function but only pointerUp.
editor.pointerUp(...).
Currently, the below log doesn't help much, as a "null pointer dereference" can have many causes:
-First, what is the frequency of the crash? Is it occuring on a specific release of the Android?This is not sure, our development environment is only Android 8.1.
-Can you confirm the language resources are aligned with the release of the iink SDK? E.g. are you using the iink SDK 2.0 with the corresponding 2.0 language resources? Using the resources from the 2.0 release with the iink SDK 1.5 could indeed cause such issue.Both language and sdk are 2.0
-Do you have a scenario that allows to reproduce? If so, could we have it?
-Ideally, would you have a project that allows to reproduce?
-If you can reproduce, could we have a log file? This can be done setting the "debug.log-file" configuration (of course, replace PATH with the directory where you want to store your log file): engine.getConfiguration().setString("debug.log-file", "PATH/iink.log");I can add a log according to your instructions, reproduce it again, I will send it to you
Olivier @MyScript
Dear Hedy,
thank you for the update.
Using Android 8.1 is not likely to cause any issue, we have daily tests running on the latter.
When you have a log a scenario to reproduce, please let us know.
Best regards,
Olivier
Hedy Jiang
Hi Olivier @MyScript,
I have this problem again, the log is linked below. I found it most likely to happen in a scenario like this:
1. Create an editor, package, part in thread one; pass in data for batch identification.
2. Create an editor, package, part in another thread; then use incremental identification.
https://drive.google.com/drive/folders/12YVrobCSyevnHVLsQmLi5jjhR4tU43Eg?usp=sharing
Hedy Jiang
So I wonder if there will be a problem with two editors working at the same time
Olivier @MyScript
Dear Hedy,
thank you for the update and log.
We will investigate and keep you updated.
Best regards,
Olivier
Olivier @MyScript
Dear Hedy,
we investigated both the iink log and the logcat, but unfortunately these do not help much:
-The iink log doesn't contain the crash information
-Regarding the logcat, it doesn't indicate an error on the iink side, but only on the native side. We would need a complete logcat with all the iink calls.
Can we have the full logcat? Also, would you have a project that would allow us to reproduce? It would help understand how you deal with threads.
Thank you,
Best regards,
Olivier
Hedy Jiang
I found the reason for the crash, the way to reproduce is simple:
1. Create an engine
2. Create and open two packages. package1,package2
3. Create and open two Parts. part1,part2
4. Create two Editors: editor1, editor2
5.Editor binds part1 and part2 respectively
6. The editor1 performs batch identification, and executes part1.close() and editor1.close() after the identification is completed;
7. When editor2 does incremental identification, it will crash when editor1.pointerDown(...) is executed.
Summary: The reason for the crash is because of ediotr1.close(), if the close is not performed, the fifth step performing incremental recognition will not crash.
Doubt: Why does the shutdown of editor1 affect the recognition operation of editor2?
Olivier @MyScript
Dear Hedy,
thank you for the update.
Honestly, the scenario is not clear to me.
At point 7, you say "When editor2 does incremental identification, it will crash when editor1.pointerDown(...) is executed"
And in the summary: "The reason for the crash is because of ediotr1.close(),"
Is it the editor1.pointerDown or the editor1.close() that causes the crash?
Also, do you have an exception that is raised?
Thank you,
Olivier
Olivier @MyScript
Dear Hedy,
Currently, I was able to reproduce the crash.
We keep you updated.
Best regards,
Olivier
Olivier @MyScript
Dear Hedy,
after doing further investigation internally, we have 2 following questions:
-Do you have 2 separate editors? (can you check in debug mode both editors have different references?)
-Do you have 2 different renderers (e.g. a renderer with a null render target in batch mode, and a "standard" renderer in incremental)?
Indeed, it is likely that you have either an editor or renderer shared in between both threads, and one thread is likely to destroy the object while still used by the other.
Can you please check this? Otherwise, can you please provide us with full project that allows to reproduce?
Also, we are questioning the reason you are using 2 thread, as this is battery and CPU consuming.
Thank you,
Best regards,
Olivier