Fresh install. OSX 10.10.5. I found a post several years old that mentioned a solution of making sure 127.0.0.1 (null) was not in /etc/hosts. No effect.
Here's a dump of the error:
Process: MAMP [2867]
Path: /Applications/MAMP/MAMP.app/Contents/MacOS/MAMP
Identifier: de.appsolute.MAMP
Version: 3.4 (3.4)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: MAMP [2867]
User ID: 962435817
Date/Time: 2015-11-09 11:29:13.754 -0500
OS Version: Mac OS X 10.10.5 (14F1021)
Report Version: 11
Anonymous UUID: C3B21FD3-E569-950C-7452-43A3D5CEDC99
Time Awake Since Boot: 1300 seconds
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
VM Regions Near 0:
-->
__TEXT 0000000100000000-0000000100015000 [ 84K] r-x/rwx SM=COW /Applications/MAMP/MAMP.app/Contents/MacOS/MAMP
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 de.appsolute.MAMP 0x0000000100006a6b 0x100000000 + 27243
1 de.appsolute.MAMP 0x0000000100006d7a 0x100000000 + 28026
2 de.appsolute.MAMP 0x0000000100008b84 0x100000000 + 35716
3 de.appsolute.MAMP 0x000000010000313d 0x100000000 + 12605
4 com.apple.CoreFoundation 0x00007fff887be45c
Related
Upgrade to Xamarin Forms 5.0.0.2012 from 4.8 makes the app (only in debug mode) to freeze for few seconds for each interaction and makes tons of outputs:
Thread started: <Thread Pool> #41
[Mono] GC_BRIDGE waiting for bridge processing to finish
[Mono] GC_TAR_BRIDGE bridges 0 objects 0 opaque 0 colors 0 colors-bridged 0 colors-visible 169 xref 4 cache-hit 0 cache-semihit 0 cache-miss 0 setup 0.07ms tarjan 0.09ms scc-setup 0.06ms gather-xref 0.00ms xref-setup 0.00ms cleanup 0.00ms
[Mono] GC_BRIDGE: Complete, was running for 0.05ms
[Mono] GC_MINOR: (Nursery full) time 15.02ms, stw 18.82ms promoted 1445K major size: 33920K in use: 32001K los size: 9472K in use: 7121K
Thread started: <Thread Pool> #42
Thread started: <Thread Pool> #43
Thread started: <Thread Pool> #44
Thread started: <Thread Pool> #45
Thread started: <Thread Pool> #46
Thread started: <Thread Pool> #47
Thread started: <Thread Pool> #48
Thread started: <Thread Pool> #49
Thread started: <Thread Pool> #50
Thread started: <Thread Pool> #51
[Mono] GC_BRIDGE waiting for bridge processing to finish
[Mono] GC_TAR_BRIDGE bridges 0 objects 0 opaque 0 colors 0 colors-bridged 0 colors-visible 169 xref 4 cache-hit 0 cache-semihit 0 cache-miss 0 setup 0.07ms tarjan 0.09ms scc-setup 0.06ms gather-xref 0.00ms xref-setup 0.00ms cleanup 0.00ms
[Mono] GC_BRIDGE: Complete, was running for 0.07ms
[Mono] GC_MINOR: (Nursery full) time 11.92ms, stw 14.43ms promoted 926K major size: 34896K in use: 32961K los size: 12544K in use: 10620K
[mono] Full thread dump:
[Mono] GC_TAR_BRIDGE bridges 0 objects 0 opaque 0 colors 0 colors-bridged 0 colors-visible 169 xref 4 cache-hit 0 cache-semihit 0 cache-miss 0 setup 0.07ms tarjan 0.09ms scc-setup 0.06ms gather-xref 0.00ms xref-setup 0.00ms cleanup 0.00ms
[Mono] GC_BRIDGE waiting for bridge processing to finish
[Mono] GC_BRIDGE: Complete, was running for 0.07ms
[Mono] GC_MINOR: (Nursery full) time 13.09ms, stw 15.10ms promoted 860K major size: 35728K in use: 33849K los size: 17664K in use: 15619K
[Mono] GC_TAR_BRIDGE bridges 0 objects 0 opaque 0 colors 0 colors-bridged 0 colors-visible 169 xref 4 cache-hit 0 cache-semihit 0 cache-miss 0 setup 0.07ms tarjan 0.09ms scc-setup 0.06ms gather-xref 0.00ms xref-setup 0.00ms cleanup 0.00ms
[Mono] GC_BRIDGE: Complete, was running for 0.07ms
[Mono] GC_MINOR: (Concurrent start) time 3.81ms, stw 13.08ms promoted 1K major size: 35728K in use: 33851K los size: 17664K in use: 15619K
[Mono] GC_MAJOR_CONCURRENT_START: (LOS overflow)
[Mono] GC_BRIDGE waiting for bridge processing to finish
Any idea how to bring back useability of a debugger?
removing a CachingStrategy="RecycleElement" from ListView was a partial solution
Xamarin garba collection runs often
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 am trying to understand the behaviour of memcached by running memaslap against it.
The command I use is
memaslap -s localhost:11212 -T 64 -c 64 --verbose -S 1s -t 30s
and this is the output I get (on local machine)
Get Statistics (3157196 events)
Min: 36
Max: 17957
Avg: 545
Geo: 533.99
Std: 167.05
Log2 Dist:
4: 0 0 11 271
8: 2813 1379137 1706845 66407
12: 1110 446 152 4
Set Statistics (350829 events)
Min: 60
Max: 16184
Avg: 547
Geo: 536.33
Std: 161.65
Log2 Dist:
4: 0 0 3 28
8: 313 151210 191252 7861
12: 112 40 10
Total Statistics (3508025 events)
Min: 36
Max: 17957
Avg: 545
Geo: 534.22
Std: 167.17
Log2 Dist:
4: 0 0 14 299
8: 3126 1530347 1898097 74268
12: 1222 486 162 4
cmd_get: 3157252
cmd_set: 350837
get_misses: 1716802
written_bytes: 608669765
read_bytes: 1610227982
object_bytes: 381710656
Run time: 30.0s Ops: 3508089 TPS: 116914 Net_rate: 70.5M/s
As you can see I have get_misses which amount to 1716802, which is more than 50% of the get requests sent by memaslap. I am curious about what a get_miss means. I checked the docs at
http://docs.libmemcached.org/bin/memaslap.html
and plainly says
get_misses
How many objects can’t be gotten from server
What does it mean to not get a key from server? Is it because the key is not present or is it because of latencies?
If its because the key is not present, what exactly is memaslap testing by sending this request?
It says how many times we've got cache miss while running the get command, in other words - how many times key was not found.
The main reason why there are cache misses is eviction. Memcached throws some items out of memory to free space for the new ones.
Number of get_misses should drop if memcached would have more RAM to use (for instance: -m 1G for 1 Gb of RAM)
HI got the this crash report on device log and I am using the ad hoc build.
I didn't find where it was crashed "0 ??? 0x3ec3b04c 0 + 1053012044"
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x3ec3b04c
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
<b>0 ??? 0x3ec3b04c 0 + 1053012044 </b>
<b>1 libgcc_s.1.dylib 0x303d29c0 _Unwind_SjLj_Unregister + 24 </b>
<b>2 ??? 0x00000018 0 + 24</b>
</pre>
Probably, your application tried to access released variable. While debugging you can use NSZombie to detect such variable before receiving EXC_BAD_ACCESS.
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.