I'm new to Mac. So far when restarting everything worked reliably as it did before and was more or less in the same state.
Can I as a dev lean on not losing any state information when restarting? Can every application be restored completely and when does data loss occur? Are there any known bugs? Can I leave my debugger at a point in my application, restart/sleep and expect to be in the same state with my debugger?
Before getting too comfortable with the feature I want to know how much I can rely on it to restore everything to the previous state, otherwise I will be more cautious with restarts, so I think this info is helpful for any dev using Mac OS X as a platfom to develop.
Applications to not get restore state functionality magically but they support APIs that help doing it. Some applications do it well, others less well and others not at all.
In practice, for the applications that support it, it works quite reliably, provided the logout went cleanly and you've not out of diskspace or something similar fatal.
Related
I'm using version 14.03.
Anytime I open UFT, Cortana, or even Windows Shell Experience Host if I remove Cortana, starts being very slow and CPU hungry. It stays that way until I log off or reboot. Cortana is the process that handles the start menu and searches so it's very noticeable when it is slower.
the installation guide mentions that Cortana should be disabled during UFT install, which I tried. It seemed to have fixed the issue at first, Cortana stayed responsive for a while after I opened UFT but it ended up going back to being slow later on. Now, after a reboot, it reverted back to the old behaviour of being slow as soon as UFT is launched
Another thing worth noting is that as soon as I uninstall UFT, Cortana works well again (no reboot).
What could be causing this?
I'd suggest moving this subject to https://superuser.com/ community.
It indeed sounds like a real conflict between Unified Functional Testing and Cortana. not sure that you, as an end-user, can solve it.
First, I'd suggest the obvious - contact support of both companies, and update to the latest versions.
Second, try to collect as much information as you can:
Process Monitor - filter by the relevant processes (Cortana process name is SearchUI.exe, but I don't know about UTF).
Microsoft Event Viewer - try to seek for events in the exact time of the issue.
I have a macOS application that is integrated with Crashlytics. If I run it as an agent, everything seems to work fine. But when I run it as a daemon, the crashs and errors don't show up on the web panel.
I'm thinking the problem might be that crashlytics uses a framework that is not daemon-safe.
Apple documentation regarding the subject says:
If your daemon uses frameworks that aren't daemon-safe, you can run
into a variety of problems.
Is this really the issue? Is there a workaround so I can get it to work?
Former maintainer for the Crashlytics SDK on Apple platforms here. However, I haven't been with the organization for a while, so my information could be out of date. You should definitely reach out to them for assistance. However, I'll still give this a shot.
A number of others have asked for this kind of functionality in the past, and from what I know, have successfully integrated Crashlytics into non-UI processes. There are some things to watch out for, though. I'm also aware of the daemon-safe issue, and that could be a problem. However, I'm unsure of how it might manifest itself.
When you say agent vs daemon, are you talking about per-process vs per-user launchd jobs, or something else? One thing I can be fairly certain of, is Crashlytics does not support multiple processes with the same bundle id running simultaneously. If there can be multiple copies of your process running at the same time, you cannot make this work. Even if it seems like it does work sometimes, it will not work reliably, at best, can could lead to serious issues at worst (potentially crashes).
One thing that is absolutely essential for correct operation is a main runloop. Crashlytics will definitely not work correctly without one.
Crashlytics also requires an Info.plist. This is actually possible to add to standalone binaries, but often trips people up. I'm guessing you figured this one out.
On macOS, Crashlytics integrates a bit with AppKit, to improve exception reporting. If I recall right, it's possible to just skip this integration completely, as outlined in the docs.
Another thing that Crashlytics relies on is a standard user file system home directory. There must be a ~\Library directory present with the standard internal structure. This one might be problematic for launchd daemons, since they run as root.
Keeping those things in mind, I'm pretty sure it's possible to make this work. There could be some things I'm not remembering, as it's been a while. However, one thing I definitely do know is this is a bit of a gray area. It works, but wasn't an explicit design goal. It might now be unsupported. You should definitely check in with them about this before shipping something.
We've started work on a project using c9 and are generally very pleased with the level of the product.
However, Over the past few days I have repeatedly experienced the loss of huge amounts of work I did.
For example: I have done work on a file at home, then went in the morning to the office and continued seamlessly - after that, I returned home and experienced the following issue: The preview of the project reflected the work I had done, but the file in the IDE did not. Furthermore, the file history indicated that I indeed worked and saved files, but the history itself did not contain the changes. CLosing the file and re-opening it, or dealing with it in any way caused the site preview to revert as well, and all the work seems to be permanently lost with no trace I ever did it.
This, in addition to being extremely frustrating, also raises a red flag as to the ability of c9 to act as an IDE in any kind of actual production scenario.
If there's anything you can say to me, please do, because I really like the idea, interface and functionality. Otherwise, bye-bye, I'm going back to the old ways.
Thanks for the report, and sorry to hear about these issues you encountered. We did run into a regression this week that could cause such behavior in rare cases. We're releasing a fix for this issue later today! We take such issues very seriously, and we made sure it cannot happen again.
Should you run into problems like this, please contact our Support department at https://support.c9.io directly, as we keep very granular levels of backups and we can easily restore any work you may have lost. StackOverflow is generally better suited for development-related questions.
Hope this helps!
Best,
Ivar
I am experiencing the exact same issue as this fellow, and cant seem to find any real solutions to the issue. The only solution I've been able to find so far that works it not maximizing VS. Keeping VS in windowed mode fixes the problem completely, but as soon as it returns to maximized state UI elements no longer redraw unless the stale area is put under new active focus. This makes it impossible to develop and I'm forced to return to windowed mode. I've tried disabling hardware acceleration with no luck. Any Ideas?
There are a handful of feedback reports at connect.microsoft.com that describe a similar problem. But none that ever evolved to a solution, most typically the programmer that filed the report stopped responding when asked to provide additional diagnostics.
Clearly this is an environmental problem, something is wrong with your machine. VS2012 uses WPF for rendering, it puts non-trivial demands on the machine. You do need a solid video driver and a functional DirectX stack to make it work without problems. This tends to be an issue in general, video drivers are by far the most problematic kind of driver. Problems are roughly correlated with the age of the machine and how old the operating system is.
So a good starting point is to look for a video driver update first, visit the web site of the company that made your adapter to look for the latest. Reinstall DirectX on the machine next. If you were considering a clean update of your machine before, like updating the Windows version, now would be a good time to start with a clean slate.
I am on OSX, and my system is becoming unresponsive for a few seconds roughly every 10 minutes. (It gives me the spinning beach ball of death). I was wondering if there was any way I could isolate the problem (I have plenty of RAM, and there are no pageouts/thrashing). Any Unix/OSX tools that could help me monitor and isolate the cause of this behaviour?
Activity Monitor (cmd+space, type, activity monitor), should give you an intuitive overview of what's happening on your system. If as you say it is there are no processes clogging CPU, please do take a look at the disk/IO activity. Perhaps your disk is going south.
I have been having problems continually over the years with system hangs. It seems that generally they are a result of filesystem errors, however Apple does not do enough to take care of this issue. System reliability should be a 100% focus and I am certainly sick of these issues. I have started to move a lot of files and all backups over to a ZFS volume on a FreeBSD server and this is helping a bit as it has started to both ease my mind and allow me to recover more quickly from issues. Additionally I've placed my system volume on a large SSD (240GB as I have a lot of support files and am trying to keep things from being too divided up with symlinks) and my Users folders on another drive. This too has helped add to reliability.
Having said this, you should try to explore spindump and stackshot to see if you can catch frozen processes before the system freezes up entirely. It is very likely that you have an app or two that is attempting to access bad blocks and it just hangs the system or you have a process blocking all others for some reason with a system call that's halting io.
Apple has used stackshot a few times with me over the last couple years to hunt some nasty buggers down and the following link can shed some light on how to perhaps better hunt this goblin down: http://www.stormacq.com/?p=346
Also try: top -l2 -S > top_output.txt and exame the results for hangs / zombie processes.
The deeper you go into this, you may find it useful to subscribe to the kernel developer list (darwin-kernel#lists.apple.com) as there are some very, very sharp cookies on here that can shed light on some of the most obscure issues and help to understand precisely what panic's are saying.
Additionally, you may want to uninstall any VMs you have installed. There is a particular developer who, I've heard from very reliable sources, has very faulty hypervisor issues and it would be wise to look into that if you have any installed. It may be time to clean up your kexts altogether as well.
But, all-in-all, we really quite desperately need a better filesystem and proactive mechanisms therein to watch for bad blocks. I praised the day and shouted for joy when I thought that we were getting ZFS officially. I am doubtful Lion is that much better on the HFS+ front sadly and I certainly am considering ZFS for my Users volume + other storage on the workstation due to it's ability to scrub for bad blocks and to eliminate issues like these.
They are the bain of our existence on Apple hardware and having worked in this field for 20 years and thousands of clients, hard drive failure should be considered inexcusable at this point. Even if the actual mfgs can't and won't fix it, the onus falls upon OS developers to handle exceptions better and to guard against such failures in order to hold off silent data loss and nightmares such as these.
I'd run a mixture of 'top' as well as tail -f /var/log/messages (or wherever your main log file is).
Chances are right before/after the hang, some error message will come out. From there you can start to weed out your problems.
Activity Monitor is the GUI version of top, and with Leopard you can use the 'Sample Process' function to watch what your culprit tasks are spending most of their time doing. Also in Utilities you'll find Console aka tail -f /var/log/messages.
As a first line of attack, I'd suggest keeping top running in a Terminal window where you can see it, and watching for runaway jobs there.
If the other answers aren't getting you anywhere, I'd run watch uptime and keep notes on the times and uptimes when it locks up. Locking up about every 10 minutes is very different from locking up exactly every 10 minutes; the latter suggests looking in crontab -l for jobs starting with */10.
Use Apple's Instruments. Honestly, it's helped immensely in finding hangs like these.
Periodic unresponsiveness is often the case when swapping is happening. Do you have sufficient memory in your system? Examine the disk io to see if there are peaks.
EDIT:
I have seen similar behaviour on my Mac lately which was caused by the filesystem being broken so OS X tried to access non-existing blocks on the disk and even trying to repair it with Disk Manger told me to reformat and reinstall. Doing that and reestablishing with Time Machine helped!
If you do this, then double check that Journalling is enabled on the HFS on the harddisk. This helps quite a bit avoiding it happening again.