I develop multimedial application within the Java ME platform. It's application usable for voice recording and after replaying.
I have treated many pieces of code by try/catch block, which should provide an alert in the case an exception occured. The application works fine on java emulator but on Symbian phone it seems fine but the application crashes after some minutes of working without any message and also without any system message. It just falls down, the application is abruptly terminated.
Is there any way how to find where's the problem? I've tried to surround all big pieces of code by try/catch block but the result is same.
Thanks for you advice
I recommend using the Symbian on device debugger or tracing on the device to determine the exact location of the problem.
You can log to file on the device every step that you make before it stops and after like "I'm doing XYZ" with timestamps and other stuff like variables values then try to figure out what is going on. Of course You'll get only stuff that happened before crash but it can give You some new info.
Related
I am implementing an app in Flutter, for which I need to schedule (audio) events in advance. Only after one event is completed I can schedule the next, since the duration of the event might not be known before. Each audio event is a notification sound for the user, thus scheduling and audio playback should both work while the app has no focus or the phone is locked.
I currently fail to implement these specifications and I guess I'm just not thinking the right way about it for the moment. Since I started to learn Flutter recently, there could also be just some simple misunderstandings from my part. Let me summarize what I know about background execution & native code in Flutter, please correct anything wrong with these statements:
When the App looses focus (or the phone gets locked) code execution stops.
However, inside the "primary" Dart-code, I can spawn an isolate which will run even with the phone locked or without focus on the app.
Different isolates share no memory whatsoever; they communicate via ports.
There a spawned isolate does not know anything about the flutter ecosystem, therefore it is not possible to use flutter plugins.
For the same reasons I cannot use MethodChannels as well to communicate with platform code from an isolate.
From this I conclude:
The event should be scheduled from a seperate Dart-isolate, so that locking the phone won't halt scheduling.
This isolate won't be able to play any audio file by itself, and won't be able to communicate with platform code.
Thus, it needs to communicate with the primary isolate, which can play audio. However, without the app open, the code won't respond.
Consequently, this approach cannot work?
Right now, I am stuck at this point and don't know how to continue. I guess one option could be to directly call java/swift code for the respective native platforms and handle scheduling and audio there. Yet, I hope that I just don't see a simpler option right now.
I'm in the process of designing an application that will run on a headless Windows CE 6.0 device. The idea is to make an application that will be started at startup and run until powered off. (Basically it will look like a service, but an application is easier to debug without the complete hassle to stop/deploy/start/attach to process procedure)
My concern is what will happen during development. If I debug/deploy the application I see no way of closing it in a friendly and easy way. (Feel free to suggest if this can be done in a better/user friendly way) I will just stop the debugger and the result will be WSACleanup is not called.
Now, the question. What is the consequence of not calling WSACleanup? Will I be able to start and run the winsock application again using the debugger? Or will there be a resource leak preventing me to do so?
Thanks in advance,
Jef
I think that Harry Johnston comment is correct.
Even if your application has no UI you can find a way to close it gracefully. I suppose that you have one or more threads in loops, you can add a named manual reset event that is checked (or can be used for waits instead of Sleep()) inside the loop condition and build a small application that opens the event using the same name, sets it and quits. This would force also your service app to close.
It may not be needed for debugging, but it may be useful also if you'll need to update your software and this requires that your main service is not running.
I am trying to track down the reason why my WPF application is not ending cleanly while debugging. By 'cleanly' I mean that all the windows are closed, I can see various messages in the Output window showing that the app has ended but the process is still active and the 'Stop' button in the debugger is still active.
I call the Shutdown() method but something is stopping the application from ending. I am pretty sure it has something to do with the ethernet connection to an IO device but cannot see what I am doing wrong. (When I comment out the call to connect the device the app can exit cleanly)
I was wondering if VSE 2010 can list all active threads as this might give a clue as to what is still 'alive' after the main program ends. Or is there an external tool that might help here?
You should be able to use the Visual Studio Threads window to see which threads are still active. I'm not entirely sure this window is available in the Express edition (the documentation doesn't mention such a limitation), but should you not have it, then you can also use WinDbg to list all threads. WinDbg is part of the debugging tools for Windows. You might need to install the latest version of the Windows SDK to get it.
Use the debugger first. Debug + Break All, Debug + Windows + Threads to see what threads are still running. You can double-click one and use Debug + Windows + Call Stack to see what it is doing. The typical case is a thread you started but forgot to tell to terminate. The Thread.IsBackground property is a way to let the CLR abort a thread automatically for you.
Technically it is possible to have a problem with a device that prevents a process from shutting down. The Threads window would then typically show only one thread with an otherwise impenetrable stack trace. If you use Task Manager, Processes tab, View + Select Columns, tick Handles, then you may see only one handle still in use. The diagnostic then is that you have a lousy device driver on your machine that doesn't properly support I/O cancellation. Which could leave a kernel thread running that doesn't quit, preventing the process from terminating. Very unusual, look for the reasons given in the first paragraph first.
I'm having issues around my app (basically a modified Mobile World Conference) app when I run it on the IOS Emulator in windows, verses running it directly on the IPad itself. I understand that there is a different process or involved so I don't expect it to be exactly the same.
In specific, I'm getting errors around initializing sql databases (SqlLite) with errors being
"Object Not Defined"
When I try and single step debug to the device, I get errors that feel like somehow the stack has been corrupted and I can not even debug into methods.
My question is, what are the types of differences I can look for and how to debug them? There must be some pattern of things that cause issues, I just have no idea what that is or how to figure it out. I'm use to my c# code just working on x86.
What causes simulator to behave differently? Simulator is not constrained in memory usage like a real device so you're likely to hit memory warnings on the device (and crash if you don't handle them properly). The code itself, however, runs faster so race conditions between threads are more likely, so watch out for that. Don't talk to database from different threads, or at least use proper locking. And of course there are AOT limitations which occur only on the device. Your LINQ problem sounds like a AOT problem to me.
I have a console app where rendering is done via D3D. Now, I created a ConsoleCollection class that could house and render several instances of such console. Unfortunately, now I get an error saying "Attempted to read/write protected memory" at the DrawPrimitives() stage, and I suspect this is due to the creation of more than one device (but am not sure).
Can someone suggest what I can try to figure this out?