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
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
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?
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.