Strange error on file generation on EHS5 | Thales IoT Developer Community
May 26, 2021 - 6:59pm, 2501 views
Hi everyone.
This is the first message I write on this community, so please be excuse me if I write the message on the wrong forum.
I am porting some Java code from some Gemalto TC65/TC65X board to the new version of EHS5 board. I have fix some small errors so far. However I am facing some strange error. At the beginning of my program I generate some files. Using TC65/TC65X boards theres is no problem, however on EHS5 came out the following error:
cannot write file
java.io.IOException: cannot write file
- com.sun.io.j2me.file.DefaultFileHandler.write(), bci=0
- com.sun.io.j2me.file.Protocol.writeBytes(), bci=13
- com.sun.midp.io.BaseOutputStream.write(), bci=43
- src.ai.c(), bci=115
- src.p.a(), bci=76
- src.main.<init>(), bci=1177
- java.lang.Class.newInstance(), bci=0
- com.sun.midp.main.CldcMIDletLoader.newInstance(), bci=69
- com.sun.midp.midlet.MIDletStateHandler.createMIDlet(), bci=63
- com.sun.midp.midlet.MIDletStateHandler.createAndRegisterMIDlet(), bci=17
- com.sun.midp.midlet.MIDletStateHandler.startSuite(), bci=24
- com.sun.midp.main.AbstractMIDletSuiteLoader.startSuite(), bci=38
- com.sun.midp.main.CldcMIDletSuiteLoader.startSuite(), bci=5
- com.sun.midp.main.AbstractMIDletSuiteLoader.runMIDletSuite(), bci=134
- com.sun.midp.main.AppIsolateMIDletSuiteLoader.main(), bci=26
This happens on the middle of the second file creation. I have used some delay code ("Thread.sleep(ms)") trying to avoid some problem on the speed of the file creation. The strange thing that I have found is that the error always happen after 5 minutos of the start of the file creation.
I think that the problem could be something about configuration. However I do not find the problem. Any idea? Thanks a lot!
PD: Some info
ati1
Cinterion
EHS6
REVISION 04.013
A-REVISION 01.000.06
AT^SJAM=5
^SJAM: "a:/JRC-1.60.02.jad","Java Remote Control MIDlet Suite","Cinterion","1.60.02",
Hello,
It looks like your code is using com.sun.midp.io.j2me.storage.File class for file operations which is probably no longer supported. Please see javax.microedition.io.file.FileConnection interface.
And it looks like your code is obfuscated which makes it harder to debug.
Best regards,
Bartłomiej
Hi Bartłomiej,
Thank you for your reply. I'm currently using the "javax.microedition.io.file.FileConnection" Fileconnection for this operations, so this is the correct one as you say. The strange think is that the program is creating some file and ends after 5 minutes of execution. I have used some delay and the program keeps exiting at 5 minutes, however I can create fewer number of data in the files.
Is there any test that I can do to find the problem?
Tank you in advance.
Hello,
For easier debugging you can build the code that is not obfuscated, add debug outputs to the program so that you could trace what is happening, make sure that your program always closes the streams and file connection objects when no longer needed, cleans all the resources on exit in destroyApp() method. Please also make sure that there is a free space on the module's FFS.
Regards,
Bartłomiej
Hi Bartłomiej,
I trying to discover what is happening with my code. The problem happens when some files generation is doing. This operation takes a while. If I reduce the number of data to write the program works fine. The code that fails seem to be ok:
for (i=0;i<n;i++)
{
try {
objOutputStream.write(r.data, 0, r.data.length);
} catch (Exception ex) {
System.out.println("Error writing a register of size " + Integer.toString(r.data.length));
System.out.println(ex.getMessage());
ex.printStackTrace();
}
}
The program fails after about 5 minutes generating these files. The problem is not the space in the modem memory. After files generation, the program works fine without any error.
This program has also worked for previous versions of this modem. So, Is there any new constrain on file writing that may affect this process?
Thank you a lot for your help.
Regards.
Hello,
This code fragment looks fine but it is too small to say anything. Can you share more code?
How many files are created? Are many files creates simultaneously by many threads? Is the file handler reused or closed?
Have you removed all the old TC65 libraries from the project and connected the new ones only?
Regards,
Bartłomiej
Hi Bartłomiej,
I have two classes that manage files and internal Databases:
In the initialization code I have some code like this one for database creation:
If file generation last less than 5 minutes, for example only one of this files is needed to generate, then generation ends successfully and the code works with no issues. I do not find what the problem is. Any idea?
Thanks a lot for your time.
Hello,
I run your code on EHS5-E REVISION 04.003 A-REVISION 01.000.04. I created Register class which creates and holds a dummy byte table.
The MIDlet was creating files with unique names in a loop and writing to them for much longer than 5 minutes until the file system was full. Then it thrown an exception:
[15:57:59:204] Excepcion createStorage data_55.txt
[15:57:59:205] java.io.IOException: cannot write file
[15:57:59:205] - com.sun.io.j2me.file.DefaultFileHandler.write(), bci=0
[15:57:59:205] - com.sun.io.j2me.file.Protocol.writeBytes(), bci=13
[15:57:59:205] - com.sun.midp.io.BaseOutputStream.write(), bci=43
[15:57:59:205] - Storage.createStorage(Storage.java:45)
[15:57:59:205] - Database.openDatabase(Database.java:51)
[15:57:59:205] - TestMidlet.startApp(TestMidlet.java:31)
[15:57:59:205] - javax.microedition.midlet.MIDletTunnelImpl.callStartApp(), bci=1
[15:57:59:205] - com.sun.midp.midlet.MIDletPeer.startApp(), bci=5
[15:57:59:205] - com.sun.midp.midlet.MIDletStateHandler.startSuite(), bci=261
[15:57:59:205] - com.sun.midp.main.AbstractMIDletSuiteLoader.startSuite(), bci=38
[15:57:59:206] - com.sun.midp.main.CldcMIDletSuiteLoader.startSuite(), bci=5
[15:57:59:206] - com.sun.midp.main.AbstractMIDletSuiteLoader.runMIDletSuite(), bci=134
[15:57:59:206] - com.sun.midp.main.AppIsolateMIDletSuiteLoader.main(), bci=26
How many files does your application create for this 5 minutes? Or there are only 3 files but much bigger?
The code you provided opens a file connections and keeps them. So I suppose that your app is consonantly writing to these files.
Maybe it is the case that the same file is open by another thread.
BTW where in your application is the initialization code executed? Comparing the stack traces it looks like you do it in the MIDlet constructor. Maybe this is the case. The constructor should be executed fast. Also startApp() method which I used for simplicity is not the right place for such a long operations. It should also be left as soon as possible. The application logic should be placed in a separate thread. This is quite important because untill startApp() is finished destroyApp() cannot be executed when the MIDlet is stopped. And destroyApp() should contain the cleanup code.
However when I moved the code to the constructor the MIDlet still run to the end of FFS space.
Do you still obfuscate the code for these tests. Try not to. Maybe this is introducing some problems. You may also try to isolate the problem by switching off some of the functionalities to find the simplest code that still reproduces the problem.
BR,
Bartłomiej
Hi Bartłomiej,
Finally I have solved the strange error. As I was thinking, the problem was about a configuration issue. In the initialization code, the Watchdog system is started. In a main loop the code calls Watchdog.kick() as usual. However, the files creation is made outside the main loop. In previous releases of EHS5, the process last less than time configured in the watchdog system. Now, the process is slower and this is why the code crashes. Using Watchdog.kick() inside the file creation routine the problem is fixed.
Probably, some part of the hardware of EHS5 rev4 is slower than rev3.
Thanks a lot your help and time.
Hello,
Thank you for the feedback.
If the watchdog was not kicked in time the module would reboot. Was it the case here? I haven't seen it mentioned before.
Best regards,
Bartłomiej