I have a Symbian application which is running fine for a while but after requesting
the same sequence of operations for the 10th time or so the Kernel suddenly crashes and
I get the following error message:
FAULT: KERN 0x00000004 (4)
Could anyone help me out what could cause such a Kernel fault?
Many thanks!
From Forum Nokia:
This fault is raised when a system thread has panicked or terminated
causing the entire system to re-boot.
In Symbian a thread can be marked a system thread if it is responsible for some fundamental OS service which will always be running. Examples include the file server (file-system) and the windows server but there are others.
In your case it depends on what your application is trying to do. I'd dare guess there is an invalid use of the Symbian APIs or that you're not freeing some resource properly.
Related
I have got some problems on my app right now. I would like to create a CIContext with :
CIContext *myContext = [CIContext contextWithOptions:nil];
But when starting the app, this line return the following message in console : "BSXPCMessage received error for message: Connection interrupted"
This message come when I launch the app on iOS 8 (simulator or device), but not with an iOS 7 simulator (I don't have a device to try). I tried many things to solve this like try it in another projet, on another Mac, call this method on another file... I think it come from iOS 8.
It don't look to change my image processing (what I use the context to), but if there is a warning, there is a problem to solve.
Thank for your help :)
I'm having the same problem: I get the "BSXPCMessage..." message in iOS 8, but not iOS 7.
I traced it to where I create the CIContext:
self.ciContext = [CIContext contextWithOptions:#{kCIContextUseSoftwareRenderer : #(NO)}];
If you set kCIContextUseSoftwareRenderer to YES, the error goes away. Maybe iOS 8 requires you to enable CPU rendering?
connection interrupted means that the XPC connection in question was interrupted (either by the remote of the connection quitting or possibly crashing). Assuming the other side is an XPC Service, App Extension, or Launch Daemon, this is usually not fatal and the connection will be restored by launchd restarting the service.
Are there any crash logs saved to ~/Library/Logs/DiagnosticReports around this time?
Do you see anything interesting in the device's syslog at this time?
Is there anything wrong happening other than the unexpected message?
For various reasons I need to use HttpWebRequest instead of the built-in WWW class to call out to web services in our Unity project. I'm finding that Request.EndGetResponse hangs under certain circumstances. The issue is exacerbated when the debugger is attached--it does happen from time to time without the debugger, but happens close to 100% of the time when the debugger is attached. It is only happening when I'm calling a web service using HTTPS.
I plugged in Wireshark to look at the two traces. Oddly, the trace when the debugger is attached includes a "Handshake Failure" where the trace without the debugger does not. The other interesting thing is that the trace that works includes two [FIN, ACK] messages presumably from other failed attempts.
Ultimately I think I'm running into some known issues with the Mono 2.6 threadpool. That said, I don't understand what EndGetResponse is doing that could cause it to hang--I thought this was a synchronous operation. I also don't understand how attaching the debugger could affect the issue.
If there are any mono experts out there, I'd appreciate any insight!
We built our own MDM server using OSX Server and an apple mini to manage about 100 iPads. Everything worked great then ios 7 was released.
We have various pads that have different things happening to them.. some are getting the app push but the app never installs, some never recive the push at all, and some pad's have our apps disappearing...
Has anyone found what needs to be done to update the server so that it will function again? I've found 150+ page document on the apple developer site that walks you though setting up the entire process but most of it we have already, that document does not call out the changes so it's certianly not ideal at all to try to pick out what needs to be updated (I did also update the OSX Server software to the newest version)
The only real errors I have to run on right now are from the device logs.. here is what is happening.
Oct 2 11:51:14 iPad mdmd[477] <Notice>: (Note ) MDM: Transaction completed. Status: 200
Oct 2 11:51:14 iPad mdmd[477] <Notice>: (Note ) MDM: Attempting to perform MDM request: InstallApplication
Oct 2 11:51:14 iPad mdmd[477] <Notice>: (Note ) MDM: Handling request type: InstallApplication
Oct 2 11:51:15 iPad mdmd[477] <Notice>: (Error) MDM: Enterprise app installation failed.
Error: NSError:
Desc : The app “com.app.Damages” is already scheduled for management.
US Desc: The app “com.app.Damages” is already scheduled for management.
Domain : MCMDMErrorDomain
Code : 12026
Type : MCFatalError
Params : (
"com.app.Damages"
)
Oct 2 11:51:15 iPad mdmd[477] <Notice>: (Error) MDM: Command Status: Error
Error: NSError:
Desc : The app “com.app.Damages” is already scheduled for management.
US Desc: The app “com.app.Damages” is already scheduled for management.
Domain : MCMDMErrorDomain
Code : 12026
Type : MCFatalError
Params : (
"com.app.Damages"
)
Anyone know what needs to be changed? There can't be that much.. we are still pushing the apps just the device is not communicating with the server now
Let me break it down to couple of subquestions:
1) Has anyone found what needs to be done to update the server so that it will function again?
Generally speaking, nothing needs to be changed on the server. iOS 7 introduced couple of new features to MDM. However, the whole protocol is still backward compatible. So, if you have older server, it should (in the ideal world) work fine with your new iOS 7 device.
2) We have various pads that have different things happening to them.. some are getting the app push but the app never installs, some never recive the push at all, and some pad's have our apps disappearing...
Welcome to the post Steve Jobs era :) Golden iPhones, eyes popping color schemes and unbaked sofware.
I noticed serious degradation of MDM stability from iOS 6 to IOS 7, especially around app distribution. I posted about 3-4 bugs to Apple and I would recommend to do the same (hopefully, the sheer number of bug reports will force them to concentrate on it).
As you I saw apps not being installed, leaving placeholder icons behind and a lot of other crappy behavior.
3) "The app “com.app.Damages” is already scheduled for management."
This messages mean that you already tried to install it and it sits somewhere in iOS installation queue, but waits for something. I am not sure what is exactly the list of possible reasons why it waits.
One of the reason which I observer is that if a user is required to enter AppStore password for a first time, it can stuck on this for quite long time (not sure why).
We have been having this problems since iOS 7 was released. We have also been working directly with Apple and our MDM vendor since then and Apple has just recently confirmed to us that this is fixed in iOS 7.1, though Apple has not announced a release date for 7.1.
We have recently found one workaround. Using our MDM, we send a command to remove the app from the device (even though it's not even installed). Once the device processes the remove command, we are then able to push the app down to the device.
I just encountered the exact same problem as well and completely agree with instability in iOS7 MDM.
The ipad I was testing is on iOS7 and here is the result what I observed in iPCU.
Oct 25 11:41:44 Devs-iPad mdmd[312] <Notice>: (Error) MDM: Command Status: Error
Error: NSError:
Desc : The app com.custom.myapp is already scheduled for management.
US Desc: The app com.custom.myapp is already scheduled for management.
Domain : MCMDMErrorDomain
Code : 12026
Type : MCFatalError
Params : (
"com.custom.myapp"
)
Removing the MDM profile and re-installing to re-provision device didn't help as well.
In the end I wiped (factory reset) the device and the next time device pull application install command for that app name it works.
Hopefully Apple fixes this issue in next software update.
we have the same situation on 20/700 Devices managed by BES10. The only workaround for us is to install the app update outside the mdm world
I just encountered this issue on iOS 9.3.4.
ErrorChain: [ {
'ErrorCode'=>12026,
'ErrorDomain'=>'MCMDMErrorDomain',
My solution was:
Remove the app from the device in the MDM
Restart the device
After the iPad started, the app icon appeared on the home screen, but it was disabled, then i uninstalled the app on the device
Assigned the app in the MDM and pushed it onto the device
Don't know what caused the app to hang out in the install queue like that, but I worked it out after a while of troubleshooting.
I am looking for a way to monitor the state of one of my applications on OS X. There's a number of components that I need to monitor such as the status of various communication channels. If they go down, the monitoring process should be able to warn the user both on screen and via a push notification.
XPC services look promising, but if the app crashes, I presume this will take out the service as well, or am I mistaken?
My preferred solution is something which would also monitor for unexpected termination, and restart the app if it happens.
What is the best way to do this?
I think monitoring communication channels, etc. must be done by the each specific components (processes). And if the unexpected error occur that component should exit immediately to ensure proper cleanup.
For processe monitoring, below Apple Technical Q&A document will be really helpful:
Technical Note TN2050: Observing Process Lifetimes Without Polling
You could write an app which starts your main application as a child process, and waits for it to exit. It could check the exit code, and then react according to your needs.
This approach is explained here: https://stackoverflow.com/a/78095/785411
To fork() some monitoring process to run your main application as a child process, this is explained here: https://stackoverflow.com/a/4327062/785411
I think you could possibly make use of the built in facilities Launchd and CrashReporter to achieve your requirements.
Launchd is the OS X system supervisor intended for launching and monitoring background processes, and would be typically used to run XPC services. Launchd agents can react to various system events, and can be configured to restart processes in the event of them crashing ( specified via the KeepAlive/SuccessfulExit key in the property list)
Launchd can be set to react to various system events as launch event, including monitoring files and directories, scheduled times, or listening to network connections.
CrashReporter is the OS X system facility that catches and logs all process crashes. It logs through the AppleSystemLogger facility and can be accessed with the syslog tools as documented in the linked TechNote. On Mountain Lion, user process crash reports end up in ~/Library/DiagnosticReports/ , with a crashlog and plist file pair created per crash event.
I think you could use these features in a couple of ways to achieve your requirement, if launchd is responsible for running the xpc services, it can take reponsibility for restarting them on crash events, and they can be dissociated from any app crashes.
You could write a launchd agent that responds to for crash events by montioring the crash report directory (e.g. using the QueueDirectories property) for new logs and re-launches your applicaton, or presents notifications.
If each process runs in its own thread you could run a watchdog program that monitors whether the threads are alive. A script that runs ps in a loop and parses the output could do it.
You can see the various options here. See for example -C to select by command name, and -m to show all threads.
If an AccessViolationException occurs, does the faulting module related to it mean that it's a bug in that module, which in our case happens to be one of our third-party DLLs? Or is this much more complicated problem? We have contacted the makers of this module but they haven't found any bug, just suggesting possible stack corruption what ever that means. However, according to the event log a particular faulting module is always associated with the AccessViolationException. So what's truth about this? Is it a buggy third-party DLL module or something else?
Background
We're using a mutex-protected VB6 STA COM object in a .NET WCF web service running on IIS 7. Lately we have detected random System.AccessViolationException errors (caused by this object) crashing the web service completely and we're pretty helpless at the moment as we've done everything to make this COM object work with the web service. The service itself has been set to run in STA mode using the following guide: (http://scottseely.com/2009/07/17/calling-an-sta-com-object-from-a-wcf-operation/
Thanks
This is possibly related to VB6 run-time leaking upon thread termination. VB6 ActiveX DLL projects have options for "Unattended execution" and "Retain in memory" that try to mitigate these issues by keeping the run-time on a STA thread as long as possible. Ask your vendor if these options are applicable to their component.
In either case best would be to keep those STA threads from terminating, implementing a pool of them (or serializing on a single STA thread), so that VB6 run-time does not try to tear-down it's internal structures at any time (and leak handles/memory/TLS doing it).
Search for using VB6 components under COM+/MTS, might find valuable advice. And best of luck!