When we trying to execute the following command, I got the error:
WebKit Threading Violation - initial use of WebKit from a secondary thread.
Command :
instruments -w "45aba71d8e1704e30d565036d717f5cccba7047a" -t "Activity Monitor" -D out
Kindly help on this error.
That WebKit Threading Violation message sounds important, but it is meaningless. Instruments has been writing that since Xcode 6 beta without any negative impact besides confusing people. Just ignore it.
Try re-running your command, but add the "-v" flag for verbose output. This might give a lot of spam, but the cause of your issues should appear in the last few lines of output.
instruments -v -w "45aba71d8e1704e30d565036d717f5cccba7047a" -t "Activity Monitor" -D out
Related
I have a script that runs in the background which uses watch to monitor a directory for changes. This works just fine. However, I had a need for the script which runs the monitoring script to be run as daemon. The daemon is running as the same user, but now watch is returning "1 Various failures."
I suspect that there is some environment variable that is not set right, but there are too many to use trial and error to diagnose the issue. And unfortunately, "Various failures" is not very helpful. Any ideas how I might diagnose this?
The command is
watch -d -t -g ls -l
I think something like the following can be used as a work-around.
diff <(ls -l) <(sleep 1; ls -l)
I finally discovered the following on stderr.
Error opening terminal: unknown.
It was easily resolved by the answer to error opening terminal. So it did turn out to be an environment variable. I don't see this error message in the code. Perhaps it occurs when making a system call that needs the terminal.
When I run sudo bpftool prog show I get the following output
39: socket_filter name bpfprog1 tag e29cda32ba011d7f gpl
loaded_at 2019-09-08T14:21:57+0200 uid 1000
xlated 248B jited 169B memlock 4096B map_ids 30
but If I try to get the program jitted output with the following command
sudo bpftool prog dump jited tag e29cda32ba011d7f
I get an error message, as reported below:
Error: can't get prog info (3): Bad address
QUESTION: what am I doing wrong? XD
You most certainly use a bpftool version compiled from Linux 4.20 or older, and hit a bug that was fixed in version 5.0. Update bpftool, and dumping programs by tags should work again.
As a side note, I usually use program IDs or pinned path, as I find it more useful to retrieve the program I want. Depending on your use case, tags might make sense, especially if you often load the same programs without changes (so you would be sure to keep the same tags) and do not have them pinned.
Running UIAutomation tests from the command line seems to break often with new Xcode releases (judging by past posts). Having never used the command line scripting for this, I found this post from 2012: Automation Instrument from the Command Line.
The Problem: My command returns without error, without output results and without anything logged to the system console. The simulator does not even launch!
Checking some of the paths for updates (notably, the Automation trace instrument path), I came up with this command. Note the path in the first parameter (it's different than in past Xcode releases):
instruments -t "/Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/PlugIns/AutomationInstrument.xrplugin/Contents/Resources/Automation.tracetemplate"
"/Users/sohail/Library/Developer/CoreSimulator/Devices/7232A640-A9D2-4626-A2AD-37AFFF706718/data/Containers/Bundle/Application/D07FEC4B-76AD-4844-8362-08E771B81053/MyAppName.app"
-e UIASCRIPT "/Users/sohail/source/MyAppName/MyAppNameAutomationTests/TestRunner.js"
-e UIARESULTSPATH "Users/sohail/source/MyAppName/MyAppNameAutomationTests/TestResults"
This might be easier to read by selecting "raw" from this gist.
Of course:
I validated that the path specified to my .app actually exists; it came into being after a successful build and run.
I validated that in my specified output folder ("TestResults") that in fact, nothing got logged.
I validated that the aforementioned TestRunner.js file I specified, could be found at the path specified, and successfully runs in the Automation Instrument interactively with the Instruments app.
I've checked Apple's Xcode6/iOS8 pre-release documentation (login required; see section title, "Executing an Automation Instrument Script from the Command Line"), and nothing jumps out at me as wrong, since I'm just targeting the simulator.
My suspicion
I'm missing some flag or switch somewhere.
Thoughts anyone?
I saw the exact same issue, after explicitly provided -w $DEVICE parameter, my tests finally got started
instruments -t /Applications/Xcode6.app/Contents/Applications/Instruments.app/Contents/PlugIns/AutomationInstrument.xrplugin/Contents/Resources/Automation.tracetemplate
-w "iPhone 5s (8.0 Simulator)" /path/to/my/TestApp.app -e UIASCRIPT /tmp/script.js -e UIARESULTSPATH /tmp
When I run a UIAutomation script in Instruments, everything works fine but when I run the exact same script from the command line, I get this error :
Cannot perform action on invalid element: UIAElementNil from target.frontMostApp().mainWindow().tableViews()[0].cells()["ID number, Required"].textFields()[0]
Here is the Instruments command I'm using to launch the test
instruments -t /Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/PlugIns/AutomationInstrument.bundle/Contents/Resources/Automation.tracetemplate /Users/johan/Library/Developer/Xcode/DerivedData/Brokers-etvmwznhcjprybdekgtixzzsnbrw/Build/Products/Release-iphonesimulator/MyApp -e UIASCRIPT /Users/johan/Desktop/Script.js
The reason might be that UIAutomation under instruments is much slower than when run from the command line. So it might be that under instruments the element target.frontMostApp().mainWindow().tableViews()[0].cells()["ID number, Required"].textFields()[0]
exists, i.e. is valid, but from the console not yet.
Maybe you should try to wait for the element to become valid, before you perform an action on it, of to check its validity (isValid) and log it to be sure about its status.
I have a running Perl process that’s stuck, I’d like to poke inside with a debugger to see what’s wrong. I can’t restart the process. Can I attach the debugger to the running process? I know I can do gdb -p, but gdb does not help me. I’ve tried Enbugger, but failed:
$ perl -e 'while (1) {}'&
[1] 86836
$ gdb -p 86836
…
Attaching to process 86836.
Reading symbols for shared libraries . done
Reading symbols for shared libraries ............................. done
Reading symbols for shared libraries + done
0x000000010c1694c6 in Perl_pp_stub ()
(gdb) call (void*)Perl_eval_pv("require Enbugger;Enbugger->stop;",0)
perl(86836) malloc: *** error for object 0x3: pointer being realloc'd was not allocated
*** set a breakpoint in malloc_error_break to debug
Program received signal SIGABRT, Aborted.
0x00007fff8269d82a in __kill ()
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (Perl_eval_pv) will be abandoned.
(gdb)
Am I doing it wrong? Are there other options?
P.S. If you think you could benefit from a debugger attached to a running process yourself, you can insert a debugger back door triggered by SIGUSR1:
use Enbugger::OnError 'USR1';
Then you can simply kill -USR1 pid and your process will jump into the debugger.
First, please use a DEBUGGING perl, if you want to inspect it with gdb.
Please define "stuck". Busy or non-busy waiting (high or low CPU), eating memory or not?
With while 1 it is busy waiting. I usually get busy waiting (endless cycles) on HV corruption in Perl_hfree_next_entry() since 5.15. Non-busy waiting is usually waiting on a blocking IO read.
I get the correct:
`0x00007fba15ab35c1 in Perl_runops_debug () at dump.c:2266`
`2266 } while ((PL_op = PL_op->op_ppaddr(aTHX)));`
and can inspect everything, much more than with a simple perl debugger. With a non-threaded perl you have to type less.
`(gdb) p Perl_op_dump(PL_op)`
and so on.
If you have to do with perl: Inside the pp_stub function it is not a good idea to enter the Enbugger runloop, you should be in the main runloop in dump.c. Set a breakpoint to the shown line.
"error for object 0x3" on eval sound like internal corruption in the context, so you should look at the cx and stack pointers. Probably because you started it in a bad context.
I've never used gdb, but maybe you could get something useful out of strace?
strace -f -s512 -p <PID>
http://metacpan.org/pod/App::Stacktrace
“perl-stacktrace prints Perl stack traces of Perl threads for a given Perl process. For each Perl frame, the full file name and line number are printed.”