Today I visit the local system in the operation of NW.js, during the operation of flash back, from the new operation there is no problem. Do you know why? Or how to see this log?
Related
I'm an iOS dev currently working on a android app (so very inexperienced with Android).
If I leave my android emulator instance open it sends huge amounts of data, 10's of GB's per minute slowing down my network. I just left it running for a couple of hours and it has send 11TB of data (yes that "T" is correct) (for context the next item in activity monitor has sent 300mb in the same period). (All according to Mac Activity Monitor anyway).
The activity monitor item is qemu-system-aarch64. I understand this to be emulator, as soon as I close emulator this data sending stops and if I force stop this process emulator quits.
I have deleted devices and created news ones running a variety of android versions and all seem to have the same issue.
I'm confident the data is not sent by my app.
Restarting Android Studio/Emulator/the Mac doesn't change anything
I can't see any large amounts of data being send via Proxyman or Little Snitch so I have no idea what's actually being sent or how to stop it.
My next move is to re-install Android Studio from scratch but would ideally like to know what's going on to prevent it in the future if this does solve it.
Does anyone have any experience with this problem or ideas as to what causes it? Any ideas on how to see what's being sent?
Any general nudges in the right direction would be greatly appreciated!
Thanks!
When my Windows 10 app runs, it causes a process called Runtime Broker to execute, which takes up a lot of Memory space.
I know my app isn't "Memory-hungry" and it hardly takes 80 MB of RAM to execute. But from the time it starts, the Memory used by Runtime Broker keeps in increasing until the PC gets stuck.
Upon killing that process, the app is force closed by Windows.
I would have posted my source code here, if only I knew which part of the code is causing this to happen.
What are the possible technical reasons for this problem to happen, and what are the possible fixes in my code to prevent this?
Is there something wrong with my code, or is it some API that I am calling?
You can easily delete RuntimeBroker.exe and any other file. I deleted RuntimeBroker.exe and Livecomm.exe by booting a live Linux Dvd and after loading go and mount the c: drive then simply navigate to the file and delete it. Done!
Runtimebroker seems to hold about 60k per file held via StorageFile objects. It's still a bad problem and the only solution is to not hold on to very many of these.
Microsoft just never does anything about this.
Update: Microsoft seems to have quietly ditched UWP. The replacement has "WinUI" and is probably called the Windows App SDK at the moment. No more runtimebroker.exe.
I sent my first desktop OSX app out to a small circle of testers today. One user cannot get past the splash screen.
I am wondering how one might debug something like this? Would I somehow write NSLogs to a file? Or does OS X have some sort of utility? I assume I need some sort of logging capability, right?
You can write your logs to file quite easily (not via NSLog, but just plain writing NSString to disk via writeToFile if you want to). You can also have your logs automatically uploaded to your server if you have one using NSURLConnection with a POST.
I prefer the latter because it requires little intervention from the testers, and happens automatically.
Distribution builds are not ment to be debugged or else it would have been development build.
You can how ever sync your device with itunes and then get the crash report(if you want to know the source of crash).from appdata.
reffer to this link. if you want to debug make a debug build with development provisoning. in your case ask the tester to send you the crash report and you keep the ipa or app file safe you will need it to read the crash report.
I asked this question over on the Apple Communities and got a grand total of ZERO responses. You guys seem a whole lot smarter, so thought I would ask here to see what you think.
An error has started occuring when I attempt to trigger an Applescript via an external process. The console error is as follows:
12/09/2012 11:01:39.205 osascript[269]: Scripting addition loading restricted to system domains because this process has mixed credentials (issetugid=0 r/e uid=501/0 gid=20/20)
When I run the script locally on the Mac(Mini - Mountain Lion 10.8.1) it works perfectly.
What is happening is as follows.
I have a MacMini as a music server in a home automation environment powered by a Crestron processor. The MacMini is connected to two zones, one via the Optical output and another to a DAC from one of the USB ports. When I selected "Listen to iTunes" in one of the two zones the controller sends a command via UDP to a program running on the MacMini which triggers the scripts to change to the appropriate audio out.
All was working well until yesterday when all of a sudden the program triggering the script, whilst reporting that it has executed the correct script correctly, isn't switching the output and the above message is appearing on the console.
I have read what I can on here and as such have reset the PRAM and SMC (all three dongs...) and deleted the script triggering program, run Clean My Mac and rebooted, all to no avail.
Can anyone help me with this, it has to be something simple given that it was working...surely? I haven't run an update or changed anything else that I can think of.....
Any and all thoughts and input would be greatly appreciated.
Thanks
Marc
From the error it seems that you have an add-on to applescript called a "Scripting addition" installed, and that's causing the error. Most likely you do not need this add-on to perform your applescript code. So I would remove all scripting additions from my system and see if the applescript still works.
Search your system for scripting additions... ~/Library/ScriptingAdditions and /Library/ScriptingAdditions.
If you do need to do something that the scripting addition is doing for you, then there's probably other ways to perform the same task without the add-on.
I have a cocoa app which uses core data. Everything seems to be working fine.
However, in a very specific scenario the app was behaving very strangely for our client.
In particular the logs shows this appearing in the output many times (which I've never seen in my testing):
Core Data: annotation: -executeRequest: encountered exception = Updating max pk failed: with userInfo = {
NSSQLiteErrorDomain = 14;
}
Has anyone ever seen this message and do you know what it means? I've tried googling it but found no information other than a few message boards regarding the Growl app having similar problems, with no solution yet available.
Sorry that I can't be more specific regarding what causes this as I'm not even sure myself. I know how to reproduce this on the client's machine but this message seems very random.
I was hoping someone could give me some more information as to what this error means exactly so that I can maybe narrow it down some more. Right now I'm pretty clueless.
Note: This appears on a macbook pro running 10.7.2 (if that matters).
Thanks for any kind of help you can provide, even something vague would help me at this point.
Update:
The managed context "save" method also fails with the following error:
The operation couldn’t be completed. (Cocoa error 134030.)
This is not really a Core Data problem as such, but more an issue of you process running out of file descriptors.
Each process has a limited number of file descriptors. If you run out, Core Data (and many other things) will stop working, because they can no longer open files -- any they'll fail.
First of all, make sure you're not leaking file descriptors, i.e. make sure you close files when you no longer need them.
I'm not sure what kind of changes you're trying to track. Take a look at Tracking File-System Changes.
If you're on 10.7, take a look at dispatch sources and DISPATCH_SOURCE_TYPE_VNODE for a very powerful tool to track file system changes (corresponds to kqueue, but is easier to use).
Core Data also gives this error in a Sandboxed app when it tries to save DB to a location where it doesn't have full read/write access to (if a user opens file for example, Core Data will be able to read/write this file, but not anything else to the same folder).
Core Data fails to write the temporary _journal file to this folder and reports this error.