im wondering if operating systems can be a cause of a crash, example if I have a code, is it possible for it to crash under windows environment but not on linux? or is this impossible?
The simplest example is come code where your intention is to make it platform compatible but your have a bug in your code so it crashes on one OS but not on the other. Pseudo code:
if (osIsLinux())
laodLunixDriver(); // causes an exception
else if (osIsWindows())
loadWindowsDriver(); // works
Note how laodLunixDriver() is a faulty function that may cause the program to crash.
Another good option for an OS specific crash is accessing files.
ifstream file("c:\\myfile.file");
may work on Windows, but crash on Linux.
Related
I try to open a labview application for a bench test acquisition coupled to e.bloxx network (GANTNER INSTRUMENTS), it shows me this error
It's the application's model. it can't be used alone
This app worked fine until yesterday. My operating system is windows XP professional.
Any help!
That is not likely to be a LabVIEW error -- the NI errors do not typically use "It's" contractions, especially not without some indication of what "it" is in context. I certainly have not seen that text, nor did I find it in any of the know string files of LabVIEW. I think this is an error specific to your application, so you are unlikely to get any help from Stack Overflow. I recommend that you check with your app vendor/author.
I've installed osx 10.10 ( Yosemite ) and since then the device (NI-USB 6210) is not working anymore.
The problem is obviously driver related. I called National Instruments and they confirmed the issue, and they also told me that the problem will be probably fixed in the next release of the nidaqmx, that will happen not so soon.
So their suggestion is to downgrade to Mavericks, which kinda suck.
They also told me to check the compatibility table
http://www.ni.com/labview/os-support/i/
in order to know when if will be supported, until then I have to struggle with downgrade or find a workaround which would be the best thing. anybody found a solution to this problem lately?
Depending on your device and how you program it, you should be able to get it working on Yosemite using NI-DAQmx Base 14.0 [1].
NI-DAQmx Base 14.0 does not claim Yosemite support, but after inspecting the installer and running a few tests, here is what I have determined:
The installer, kernel extensions, frameworks, and applications are signed by National Instruments, which means Gatekeeper won't interrupt you with "are you sure you want to do this?" questions.
Both 32-bit and 64-bit LabVIEW APIs are provided.
Both 32-bit and 64-bit C APIs are provided, but a C or Cocoa application emits a warning on exit. It appears one of the components in the driver attempts to access UI elements from a background thread. My suspicion is that the LabVIEW Run-Time Engine, in which the DAQmx Base C API runs, is doing that.
Links
[1] NI-DAQmx Base 14.0 for Mac
http://www.ni.com/download/ni-daqmx-base-14.0/5060/en/
I had this same problem, and spent an evening figuring out the problem.
Apparently, the NiDaq framework tries to send a message setHandler:withData: to the appdelegate. On yosemite, this handler no longer exists, causing the exception.
If you haven't implemented such message in your own app delegate, things go bad.
But you can simply implement a dummy handler by adding this to your application delegate class :
- (id)setHandler:(id)a withData:(id) b
{
return nil;
}
this way, the framework doesn't crash !!! I still have to test if the measured data is correct, but at least i'm running again !
I created a WCF Client on Monotouch with the Silverlight SLSvcUtil.exe Tool similar to http://docs.xamarin.com/ios/tutorials/Working_with_Web_Services#Consuming_WCF_Services.
On the Simulator everything works fine but when i started it on an iPhone 4S i got the error :
Attempting to JIT compile method '(wrapper delegate-begin-invoke) :begin_invoke_IAsyncResult_this__TimeSpan_AsyncCallback_object (System.TimeSpan,System.AsyncCallback,object)' while running with --aot-only.
Any ideas?
I've called a few wcf services from monotouch without hitting any issues like this- so it can be done.
The jit error within monotouch normally indicates either that something has been removed by the linker, or that some virtual abstract method has been called (at least in my recent experience).
Can you check the linker settings for your real iPhone project? Does the problem go away if you set it to -nolink - see http://docs.xamarin.com/ios/advanced_topics/linker
If that does help, then the next step is to take a look within the wcf generated file - can you find and post some more code about the callback method in this case?
Such issues are rarely linker related, even less if the signature is a wrapper. However you can confirm this easily with Stuart's instructions.
IMO you are likely hitting a case where the AOT compiler could not predict the required code. That can happens when mixing generics and value-types (and you have a TimeSpan in generated signature). This will work on the simulator (where the JIT is used) but not when AOT'ing the application.
The best way to solve such issue is to open a bug report at http://bugzilla.xamarin.com and attach a test case that allow us to replicate the issue.
Well, while running my iPhone game on my iPhone 4 through Xcode, my app crashed (sometimes does, sometimes doesn't), and when it crashed, Xcode didn't throw me any info. In the log, I could see (gdb) written, but nothing else that could help me find the problem.
What could cause such an error? At least it should tell me something, no?
Crashes without explanation on the device itself are often due to using up too much memory; the device simply terminates the app when it has requested more memory than available. This is easy to do in game development, with all those images.
Use Instruments to track memory usage, and/or put some good memory management code in the App Delegate methods for memory warnings and always release as much as you can.
I have a vb.net project which sometimes, when running in the IDE, suddenly hangs. Normally this wouldn't be a problem. Just hit 'pause', look at the currently running threads, and find the deadlock (or whatever else).
But now I'm running into a situation where not only does the program hang, but trying to pause it causes visual studio itself to hang. In order to get control back, I have to kill the program-being-debugged's process, at which point visual studio comes back to life and says it was unable to pause execution. This is frustrating, because killing the process means the program state is lost (of course), so I don't know where the hang is.
So are there any common causes for this behavior? What should I be looking for?
if your program installs global hooks (which communicate with app) - this might be the case. A hook tries to communicate with your app (which is paused by debugger) and gets locked. And debugger is unable to receive its window messages: classic deadlock between hooked debugger (with hook dll) and a hooking app.
Finding a specific fix for a Visual Studio problem can be tricky: http://social.msdn.microsoft.com/Search/en-US/?query=visual%20studio%202008%20hang&ac=3
Additionally, not all hotfixes from Microsoft get released directly to the public. Some are only given out to customers whose systems are exhibiting a specific problem. So you have to contact Microsoft to the get the fix. They do this to limit the potential downside of releasing a hotfix that may break something else. So if all else fails, give them a call.
Here are some other things that I like to do when Visual Studio starts acting up:
Delete old breakpoints and watch variables.
With visual studio not running, delete the intellisense file (.ncb)
Clean the solution and then do a rebuild of all of the code.
Check hotfixes and service packs. I've seen a bug related to .net programming and debugging hangs. (VS hangs for me when debugging C++ 32-bit apps on 64-bit os:es sometimes.)
I just had a very similiar issue (VS fails to break execution), using Debug -> Delete all breakpoints solved the issue.
I'd check the code of the program being debugged, I'm thinking there may be an infinite loop or race condition in the code you're trying to debug. This has been the case for me in the past, especially on a single-core laptop I used to have. Can you give any information about where in the program you think execution is when you try to pause?