My research shows the general question is an exceptionally popular.
And in the main there is no one solution for all phones using CLDC/MIDP framework.
I have developed an app that works on all the phones I have tested so far (mostly nokia's) but it throws an IOException on the Samsung jet S8003.
Any ideas as to how can possibly obtain a trace on this specific phone?
I can't answer specifically for your platform, but over the years I've found that the best approach to these kinds of problems is to implement some kind of tracing facility in your code so that you can see the code path that led to the exception. See the answers to this SO question for some ideas on how to accomplish this: Logging in J2ME.
The nice thing about this approach is that it makes it a lot easier to debug customer problems when they run your app on a phone model you've never heard of, especially if there's an easy way for them to enable the tracelog and have it sent to you automatically.
After years of frustration I created a tool that does what you want: http://jarrut.sourceforge.net/
It's not as easy to setup as it could be, but it comes with a working example. After you get it working you will no longer do JME stuff without it.
Related
I'm working on a thesis about porting desktop applications to the web. Does anyone know the method or stages in doing the porting? Previously I had searched for some papers on google but it was very difficult. So I tried to ask here maybe someone can help.
in my humble opinion, there are stages / method with their own cases. Maybe if we analyze what they do and find the similiar what the others do, it seem good enough to implement in case desktop to web.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
I have a difficult WPF application, which works with PTL, many third-party libraries and network. In developer workstation it works fine (in release mode too), but when I run it in client workstation - I got stackoverflow exception in same input data. Also app crashed always in different places.
So, my questions are:
I know, that its impossible to catch stackoverflow exception by try-catch-finally. But may be exists any workaround to understand which module generate this problem?
What different between client and developer environment, if all third-party libraries are equals?
I know, that its impossible to catch a StackOverflowError exception using try-catch-finally.
It is not impossible. Just highly inadvisable, and it probably won't fix the issue. (The best a handler could do would be to abandon what ever caused the problem and try to continue. But what if the application needed the result that was being computed? Or what if the application tries the same computation again?)
But may be exists any workaround to understand which module generate this problem?
Without knowing the real cause of the problem, there is no good workaround.
How do you find the real cause of the problem? Debug the application!
What different between client and developer environment, if all third-party libraries are equals?
In general it could be any of the following:
Different Java versions
Different OS versions
Containers and/or virtualization
Different networking environments
Different external tools installed
Different file system layouts
Different users or file permissions
Different Java application configs
Different input data / databases.
and probably a few more besides. In short there are potentially lots of things that could be different that could cause different behaviors. You might be able to discount some of these as not relevant, but it is also possible to be wrong about that.
IMO, looking for the differences is the wrong approach. A better idea is to debug your application in the client environment. Read the stacktrace, read the code, attach a debugger to the JVM and set breakpoints, etc to try and find out what is actually happening.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I want to start programming a synthesizer. I reckoned that I would need to use the sound card, so I started to google. After a while, discovered many options:
- WaveOut API - I've heard that this one is outdated, so I scrapped this one.
- WASAPI - Seemed a little bit too low level for what I wanted.
- DirectSound, XAudio, XAudio2 - Seem reasonably fine, but I want to have as little latency as possible.
- Asio - Seemed like exactly what I want!
I did find a couple of tutorials and source code to get me started on audio programming. Sadly, the only one I got to work uses the waveOpen API, which I don't want to use.
Then I found this tutorial, which seemed perfect for my needs.
This tutorial is, suprisingly, the only usable (well, not that usable since I can't get it to work) resource I can find on using ASIO. Thing is, I can't get it to work. When I run the demo I get a 'Application has stopped working'-error, followed by the console output:
Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'BlueWave.Interop.Asio, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format. File name: 'BlueWave.Interop.Asio, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' at BlueWave.Interop.Asio.Test.TestConsole.Main(String[] args)
WRN: Assembly binding logging is turned OFF.To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There is some performance penalty associated with assembly bind failure logging. To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
When I try to compile, I got a whole lot of Rosie errors:
This is after I manually placed msvcr90.dll and msvcd90.dll in C:\Windows\System32 (I couldn't get them to install any other way). Ow yeah, and of course I installed ASIO4ALL before all this.
So, this is not really a question, but I'm merely asking for general advice. I think it shouldn't be THAT hard to get asio working, but at the same time a link to another resource for learning the ASIO API would be great, as well as any other advice. (Maybe it's easier to just go and try to get Xaudio2 working? I don't know...)
Thanks in advance, and sorry if you think my question is a long or boring read!
EDIT: Thanks for the reactions. I have come across the ASIOHost API by TropicalProgrammer. No idea if it's any good, but it looks promising. I'm looking into it currently. There may be better options, but I have to admit that I got my mind set on ASIO currently.
I suggest having a look at Juce which is a dual-licensed audio framework for writing both audio plug-ins and host applications. Quite a few commercial applications have been built using it.
Since your objective is to build a synthesiser, the path of least resistance is to build it as a VST plug-in. JUCE provides a host application that takes care of managing the OS's audio APIs, good documentation and numerous examples. All you will need to do is implement the render-callback for your synth.
As for ASIO, a great many pro-audio applications have been built with it, mainly because of the traditional shortcomings of the normal audio APIs on successive versions of Windows - particularly where latency or high channel-count is concerned. On Windows, ASIO uses dedicated drivers for the audio hardware and bypasses the host operating system's audio stack. I suspect Juce will take care of this for you.
Not a really helpful answer, but I decided to go with XAUDIO2. I wouldn't really say it's easy to use, but at least there are tutorials available (I use this one, but microsoft has a serie available as well).
(as at 1st June 2012)
A very simple question I would really appreciate input from others (I think we all could) who are either wondering the same or have decided to go with it (if so, any user experiences shared would be great).
I have 2 main issues which seem common on stackoverflow and on various blogs, so I know I'm not the only person experiencing them.
Occasionally my sync gets corrupted for one reason or another and the sync either fails on certain data or fails to sync altogether.
Pre populating data is essential for my app, there's no reliable way of doing this (without asking the user - which isn't reliable)
I've seen many good work arounds to both these issues but I can't help feeling that my users will encounter problems still.
I'd be really interested to learn of any experiences particularly from those that have decided to publish using iCloud and Core-Data.
iCloud has been around a while now but even on iOS 5.1.1 it doesn't seem stable enough, surely a more reliable version can't be too far away.
It is hard to answer this one without "Making statements based on opinion", but it's one worth giving partially backed up opinions on to hopefully save others some time and frustration.
My opinion is that it's just not ready. I unfortunately have an app in the wild at the moment based around CoreData + iCloud and even though we danced around a number of iCloud bugs to finally get it stable enough to pass reasonably thorough testing some users are still running into the corrupted sync states. I've spent a healthy portion of my recent life trying to make it work and am currently reluctantly reimplementing the app without Core Data. I really hope that it stabilizes soon as I genuinely like most of it.
I'm in the process of troubleshooting some memory problems we're having in our .NET WinForms application. I'm using SciTech's .NET Memory Profiler as well as dotTrace and they all seem to be indicting root allocations by static event handlers in the .NET Framework controls. From google'ing around, I've found reports of this here and here but this appears to be reported on the v1.1 of the .NET Framework and fixes promised for 2.0. We're running on 2.0 and we're still seeing these problems. The top 25 memory offenders that I've found all point to these static event handlers and specifically SystemEvents.UserPreferenceChanged. This guy went to great lengths to find a way to unwind these handlers. I haven't tried this yet, but I did try the workaround mentioned in the Microsoft support ticket, and none of them worked for me.
I'm well aware of the leak potential of event handlers (especially long living static handlers), but this one is almost out of my control. Anyone have any experience with this?
For really deep memory leak problems in the CLR, I find the best tool is windbg. If you can get past the cryptic syntax it's an amazingly effective debugger and leak tracker. The downside is it's not very intuitive to use and there is a very steep learning curve.
The best way to learn windbg though is by doing. Here are a couple of articles that talk about using windbg to track down a leak.
http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx
http://weblogs.asp.net/scottgu/archive/2006/02/02/437231.aspx
I don't know if WinDBG is going to help here. It sounds like this is truly a bug in the framework. Is there a way you can post a simple repro? If so, then I could dig into what the heck is going on and see if there is a workaround. Otherwise your better bet would be to open a ticket on Connect. They are pretty good about getting back to people.
If you did want to look into it with WinDBG, you could investigate what is going on the heap to see what is going on. Start looking at what the objects that are hanging around are being rooted by. My guess is that you'll see pretty much what you see in the profilers above. The tricky thing with WinDBG is it can tell you just about whatever you want - you have to know what questions you want answered going into it.