I'm trying to install Chromium depot tools in a Raspberry Pi but I not able to fetch anything. From the tutorial I do:
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
export PATH=/path/to/depot_tools:$PATH
Then I try to execyte a simple help command: fetch --help command. It gives the error:
pi#raspberrypi:~/experiments/build-webrtc/depot_tools $ fetch --help
Errors:
failed to resolve infra/3pp/tools/git/linux-armv6l#version:2.24.1.chromium.5 (line 27): no such package
failed to resolve infra/3pp/tools/cpython/linux-armv6l#version:2.7.17.chromium.22 (line 21): no such package
failed to resolve infra/3pp/tools/cpython3/linux-armv6l#version:3.8.0.chromium.8 (line 24): no such package
/home/pi/experiments/build-webrtc/depot_tools/bootstrap_python3: line 32: bootstrap-3.8.0.chromium.8_bin/python3/bin/python3: No such file or directory
cat: /home/pi/experiments/build-webrtc/depot_tools/python3_bin_reldir.txt: No such file or directory
[E2020-05-01T13:00:13.414783+01:00 20120 0 annotate.go:241] original error: fork/exec /home/pi/experiments/build-webrtc/depot_tools/python3: no such file or directory
[E2020-05-01T13:00:13.414904+01:00 20120 0 annotate.go:241]
[E2020-05-01T13:00:13.414950+01:00 20120 0 annotate.go:241] goroutine 1:
[E2020-05-01T13:00:13.415009+01:00 20120 0 annotate.go:241] #0 go.chromium.org/luci/vpython/python/interpreter.go:89 - python.(*Interpreter).GetVersion()
[E2020-05-01T13:00:13.415049+01:00 20120 0 annotate.go:241] #1 go.chromium.org/luci/vpython/venv/config.go:286 - venv.(*Config).resolvePythonInterpreter()
[E2020-05-01T13:00:13.415088+01:00 20120 0 annotate.go:241] reason: failed to determine Python version for: /home/pi/experiments/build-webrtc/depot_tools//python3
[E2020-05-01T13:00:13.415127+01:00 20120 0 annotate.go:241]
[E2020-05-01T13:00:13.415163+01:00 20120 0 annotate.go:241] #2 go.chromium.org/luci/vpython/venv/config.go:186 - venv.(*Config).makeEnv()
[E2020-05-01T13:00:13.415214+01:00 20120 0 annotate.go:241] reason: failed to resolve system Python interpreter
[E2020-05-01T13:00:13.415254+01:00 20120 0 annotate.go:241]
[E2020-05-01T13:00:13.415290+01:00 20120 0 annotate.go:241] #3 go.chromium.org/luci/vpython/venv/venv.go:150 - venv.With()
[E2020-05-01T13:00:13.415326+01:00 20120 0 annotate.go:241] reason: failed to initialize empty probe environment
[E2020-05-01T13:00:13.415363+01:00 20120 0 annotate.go:241]
[E2020-05-01T13:00:13.415413+01:00 20120 0 annotate.go:241] #4 go.chromium.org/luci/vpython/run.go:62 - vpython.Run()
[E2020-05-01T13:00:13.415451+01:00 20120 0 annotate.go:241] #5 go.chromium.org/luci/vpython/application/application.go:320 - application.(*application).mainImpl()
[E2020-05-01T13:00:13.415488+01:00 20120 0 annotate.go:241] #6 go.chromium.org/luci/vpython/application/application.go:406 - application.(*Config).Main.func1()
[E2020-05-01T13:00:13.415526+01:00 20120 0 annotate.go:241] #7 go.chromium.org/luci/vpython/application/support.go:46 - application.run()
[E2020-05-01T13:00:13.415563+01:00 20120 0 annotate.go:241] #8 go.chromium.org/luci/vpython/application/application.go:405 - application.(*Config).Main()
[E2020-05-01T13:00:13.415601+01:00 20120 0 annotate.go:241] #9 vpython/main.go:106 - main.mainImpl()
[E2020-05-01T13:00:13.415638+01:00 20120 0 annotate.go:241] #10 vpython/main.go:112 - main.main()
[E2020-05-01T13:00:13.415674+01:00 20120 0 annotate.go:241] #11 runtime/proc.go:203 - runtime.main()
[E2020-05-01T13:00:13.415710+01:00 20120 0 annotate.go:241] #12 runtime/asm_arm.s:868 - runtime.goexit()
I ran into the exact same issue, i.e.
python3_bin_reldir.txt - No such file or directory
failed to determine Python version
...
On Windows, it turned out that the environment variable DEPOT_TOOLS_UPDATE=0 was to blame. Once I removed that, everything worked smoothly. It seems that it stopped the depot_tools tools from properly bootstrapping on Windows.
Please try to unset this environment variable and see if it works for you.
I'm getting an error like the following (censored and trimmed to protect proprietary info):
Process: MyExecutable [7150]
Path: /Applications/Company Name/Parent App.app/Contents/PlugIns/MyExecutable
Identifier: MyExecutable
Version: 0
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: MyExecutable [7150]
User ID: 1129915948
Date/Time: 2018-03-27 11:42:12.401 -0400
OS Version: Mac OS X 10.12.6 (16G1212)
Report Version: 12
Anonymous UUID: 013E2942-CED9-22FA-438A-E3D0BA89EB5C
Time Awake Since Boot: 6200 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00007fa9bc632b10
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Bus error: 10
Termination Reason: Namespace SIGNAL, Code 0xa
Terminating Process: exc handler [0]
VM Regions Near 0x7fa9bc632b10:
MALLOC_TINY 00007fa9bc400000-00007fa9bc600000 [ 2048K] rw-/rwx SM=PRV
--> MALLOC_TINY 00007fa9bc600000-00007fa9bc700000 [ 1024K] rw-/rwx SM=COW
MALLOC_TINY 00007fa9bc700000-00007fa9bc800000 [ 1024K] rw-/rwx SM=PRV
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 ??? 0x00007fa9bc632b10 0 + 140366986816272
1 com.apple.Foundation 0x00007fffa3225051 -[NSConcreteTask waitUntilExit] + 213
2 MyExecutable 0x000000010dcfeb86 _TTSf4gs_gs_g___TF8MyExecutableP33_446BC8CF8CAA764CF050D96869CE3A5A18mySwiftFunctionFTSS7purposeSS18callbackFCSo7ProcessT__T_ + 1254
3 MyExecutable 0x000000010dcfdbb7 _TZFC8MyExecutable12MyClassP33_446BC8CF8CAA764CF050D96869CE3A5A31someSwiftFunctionfT_T_ + 215
4 MyExecutable 0x000000010dcfd985 _TZFC8MyExecutable12MyClass40someSwiftFunctionfT_T_ + 21
5 MyExecutable 0x000000010dcd8e0f main + 241
6 libdyld.dylib 0x00007fffb6ef3235 start + 1
The code in question attempts to run a terminal command by using Process (AKA NSTask in Objective-C; implemented by NSConcreteTask). It's prepared like this:
process.launchPath = "/bin/bash"
process.arguments = ["-c", bashCommand]
process.terminationHandler = callback
process.launch()
process.waitUntilExit()
It runs fine until the call to waitUntilExit. When that runs, the app crashes immediately with an output similar to that above.
For various reasons, I can't run a debugger to test this, but I can print log lines to the console. Why would it crash this hard? I even see a bus error in there for crying out loud...
Synchronous waitUntilExit() and asynchronous completion handler don't work very well together.
If you use the asynchronous completion handler waiting for exit is actually pointless.
Just delete the line
process.waitUntilExit()
I have a network program written in C using TCP sockets. Sometimes the client program hangs forever expecting input from server. Specifically, the client hangs on select() call set on an fd intended to read characters sent by server.
I am using strace to know where the process got stuck. However, sometimes when I attach the hung client process to strace, it immediately resumes it's execution and properly exits. Not all hung processes exhibit this behavior, some processes stuck in the select() even if I attach them to strace. But most of the processes resume their execution when attached to strace.
I am curious what causing the processes resume when attached to strace. It might give me clues to know why client processes are getting hung.
Any ideas? what causes a hung process to resume it's execution when attached to strace?
Update:
Here's the output of strace on hung processes.
> sudo strace -p 25645
Process 25645 attached - interrupt to quit
--- SIGSTOP (Stopped (signal)) # 0 (0) ---
--- SIGSTOP (Stopped (signal)) # 0 (0) ---
[ Process PID=25645 runs in 32 bit mode. ]
select(6, [3 5], NULL, NULL, NULL) = 2 (in [3 5])
read(5, "\0", 8192) = 1
write(2, "", 0) = 0
read(3, "====Setup set_oldtempbehaio"..., 8192) = 555
write(1, "====Setup set_oldtempbehaio"..., 555) = 555
select(6, [3 5], NULL, NULL, NULL) = 2 (in [3 5])
read(5, "", 8192) = 0
read(3, "", 8192) = 0
close(5) = 0
kill(25652, SIGKILL) = 0
exit_group(0) = ?
Process 25645 detached
_
> sudo strace -p 14462
Process 14462 attached - interrupt to quit
[ Process PID=14462 runs in 32 bit mode. ]
read(0, 0xff85fdbc, 8192) = -1 EIO (Input/output error)
shutdown(3, 1 /* send */) = 0
exit_group(0) = ?
_
> sudo strace -p 7517
Process 7517 attached - interrupt to quit
--- SIGSTOP (Stopped (signal)) # 0 (0) ---
--- SIGSTOP (Stopped (signal)) # 0 (0) ---
[ Process PID=7517 runs in 32 bit mode. ]
connect(3, {sa_family=AF_INET, sin_port=htons(300), sin_addr=inet_addr("100.64.220.98")}, 16) = -1 ETIMEDOUT (Connection timed out)
close(3) = 0
dup(2) = 3
fcntl64(3, F_GETFL) = 0x1 (flags O_WRONLY)
close(3) = 0
write(2, "dsd13: Connection timed out\n", 30) = 30
write(2, "Error code : 110\n", 17) = 17
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
exit_group(1) = ?
Process 7517 detached
Not just select(), but the processes(of same program) are stuck in various system calls before I attach them to strace. They suddenly resume after attaching to strace. If I don't attach them to strace, they just hang there forever.
Update 2:
I learned that strace could start a process which was previously stopped (process in T sate). Now I am trying to understand why did these processes go to 'T' state, what's the cause. Here's the /proc//status information:
> cat /proc/12554/status
Name: someone
State: T (stopped)
SleepAVG: 88%
Tgid: 12554
Pid: 12554
PPid: 9754
TracerPid: 0
Uid: 5000 5000 5000 5000
Gid: 48986 48986 48986 48986
FDSize: 256
Groups: 9149 48986
VmPeak: 1992 kB
VmSize: 1964 kB
VmLck: 0 kB
VmHWM: 608 kB
VmRSS: 608 kB
VmData: 156 kB
VmStk: 20 kB
VmExe: 16 kB
VmLib: 1744 kB
VmPTE: 20 kB
Threads: 1
SigQ: 54/73728
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000006
SigCgt: 0000000000004000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
Cpus_allowed: 00000000,00000000,00000000,0000000f
Mems_allowed: 00000000,00000001
strace uses ptrace. The ptrace man page has this:
Since attaching sends SIGSTOP and the tracer usually suppresses it,
this may cause a stray EINTR return from the currently executing system
call in the tracee, as described in the "Signal injection and
suppression" section.
Are you seeing select return EINTR?
I'm running a MongoDB instance using a Replica Set, when there are a lot of insert, I can see very weird statistics on faults and locked %.
How come locked % can be more than 100 ?!
Where does the faults happen, I have no logs mentioning any fault, does someone have any clue about what it means ?
insert query update delete getmore command flushes mapped vsize res faults locked % idx miss % qr|qw ar|aw netIn netOut conn set repl time
9 0 0 0 1 4 0 70.3g 141g 4.77g 20 124 0 0|0 0|1 1m 2m 10 socialdb M 18:49:49
18 0 0 0 3 1 0 70.3g 141g 4.77g 17 73.8 0 0|0 0|1 1m 2m 10 socialdb M 18:49:50
21 0 0 0 1 5 0 70.3g 141g 4.77g 18 104 0 0|0 0|1 1m 1m 10 socialdb M 18:49:51
20 0 0 0 3 1 0 70.3g 141g 4.78g 18 98.8 0 0|0 0|1 1m 3m 10 socialdb M 18:49:52
172 0 0 0 5 4 0 70.3g 141g 4.79g 133 72.8 0 0|0 0|0 7m 12m 10 socialdb M 18:49:53
76 0 0 0 3 1 0 70.3g 141g 4.8g 114 65.1 0 0|0 0|1 6m 10m 10 socialdb M 18:49:54
54 0 0 0 4 4 1 70.3g 141g 4.81g 45 90.6 0 0|0 0|1 2m 8m 10 socialdb M 18:49:55
85 0 0 0 4 2 0 70.3g 141g 4.84g 101 98.1 0 0|0 0|1 6m 11m 10 socialdb M 18:49:56
77 0 0 0 3 4 0 70.3g 141g 4.82g 78 74.5 0 0|0 0|1 4m 9m 10 socialdb M 18:49:57
72 0 0 0 3 1 0 70.3g 141g 4.84g 111 95.7 0 0|0 0|1 6m 10m 10 socialdb M 18:49:58
Is there a better (standard) monitoring tool, free ?
Not sure about the other two but this could be the answer to your first question, if you are using v2.2:
http://docs.mongodb.org/manual/reference/mongostat/The above page mentions:
locked:
The percent of time in a global write lock.
(Changed in version 2.2: The locked db field replaces the locked % field to more appropriate data regarding the database specific locks in version 2.2)
locked db:
New in version 2.2.
The percent of time in the per-database context-specific lock. mongostat will report the database that has spent the most time since the last mongostat call with a write lock.
This value represents the amount of time the database had a database specific lock and the time that the mongod spent in the global lock. Because of this, and the sampling method, you may see some values greater than 100%.
any one have any idea why application crash on this place
In code I am doing something like this
RequestOperation* requestOperation = [[[RequestOperation alloc]initWithItem:item delegate:self] autorelease];
[operationQueue addOperation:requestOperation];
Error Code
OS Version: iPhone OS 4.2.1
Report Version: 104
Exception Type: SIGBUS
Exception Codes: BUS_ADRALN at 0x7c
Crashed Thread: 0
Thread 0 Crashed:
0 libSystem.B.dylib 0x000053e4 OSAtomicCompareAndSwap32 + 0
1 Foundation 0x00023235 ____addOperations_block_invoke_1 + 37
2 Foundation 0x00022d91 __addOperations + 229
3 Foundation 0x00022cab -[NSOperationQueue addOperation:] + 11
BUS_ADRALN means that there is an address alignment problem.
I would check if the NSOperation object that is passed to [NSOperationQueue addOperation:] is valid.