Hi Jon/Rodrigo Good news... I am hopefully going to be able to give you some form of a standalone repro.
I remembered that we have a "software" media renderer, which is essentially a simulator app that can be run on a computer. So I set up an isolated test network today, consisting of a Mac connected to an Airport Extreme and I fired up several instances of our software renderer on the Mac. I then fired up a test mono app on the mac which basically consisted of a while loop that started and stopped our network stack repeatedly. Bang! A near instant sgen crash with 2.10.8... So next I tried it with 2.10.9. Sadly it did not crash even though I left it running for quite a while. So I went back and double checked, and found that I must just have been unlucky before with 2.10.9 and in fact it takes quite a while to make it crash on our main network (which has an awful lot of devices coming and going all the time). However eventually I did get another sgen crash with 2.10.9 back on the main network and will attach this to the bug report when I file it (I can't get to it right now as it's sitting on my mac and that's running on the isolated network). The native stacktrace starts with the following frames if it helps any: 0 mono-sgen 0x000a24bf mono_handle_native_sigsegv +287 1 mono-sgen 0x00004fb3 mono_sigsegv_signal_handler +334 2 libsystem_c.dylib 0x9284459b _sigtramp +43 ... So, having ascertained that I was merely unlucky first time around with 2.10.9, I was able to go away and profile on the mac with heapshot and I managed to iron out the memory leak within our stack on the Mac, which is at least something constructive for my day... So next I put my Xoom tablet onto the test network, to see if: a) I could still reproduce a memory leak on monodroid having now fixed a leak on the mac b) I could try to get you an sgen crash on droid. And the result of doing so was that: a) My app is still leaking like a sieve on android :( b) I got what looks like a hang right in the middle of a GC on droid - it did not finish doing a major collection, as per the following logcat output: ------ I/mono-gc (25026): Start major collection 17 I/mono-gc (25026): Scanning pinned roots (47360 bytes, 322/7 entries) I/mono-gc (25026): Finding pinned pointers: 966 in 2081 usecs I/mono-gc (25026): Root scan: 2 usecs I/mono-gc (25026): old generation done I/mono-gc (25026): Finalize queue handling scan for old generation: 5144 usecs 2 ephemeron roundss D/dalvikvm(21277): GC_EXPLICIT freed 32K, 30% free 14428K/20487K, paused 6ms+2ms D/dalvikvm(21277): GC_EXPLICIT freed 1K, 30% free 14427K/20487K, paused 2ms+2ms ------- The app threads were never restarted again and an ANR was the result. This was MFA v4.0.5 by the way. So the state of play is that I should be able to put together a standalone repro that demonstrates: a) A leak on droid but not on mac b) An sgen hang on MFA v4.0.5 (it took a while for this to happen, mind...) c) An sgen crash on the mac running mono 2.10.8 (near instantly). The only thing I have not managed to replicate today is an sgen crash on the mac 2.10.9 on the test network with just the software renderers running. I am going home now but will leave 2.10.9 running overnight on the test network and hopefully it too will eventually crash - and hopefully the crash will be in sgen and not in my code ;) Tomorrow I will try and put together a runnable copy of all this stuff and knock together some instructions that will help you to get it working. I'll get it across to you as soon as it's in a usable state. Cheers Iain p.s. I believe I had set my DYLD_LIBRARY_PATH correctly, and then when I examined the exports from libMonoPosixHelper.dylib, I found that the library was exporting GetNLSocket() instead of CreateNLSocket(), which suggests that support/nl.c was being built without HAVE_LINUX_NETLINK_H and HAVE_LINUX_RTNETLINK_H #defined. Perhaps someone updated that file and renamed GetNLSocket() to CreateNLSocket() but forgot to rename the function in the #else branch? (Just a guess...) -- View this message in context: http://mono-for-android.1047100.n5.nabble.com/profiling-support-in-monodroid-tp5564284p5583749.html Sent from the Mono for Android mailing list archive at Nabble.com. _______________________________________________ Monodroid mailing list [email protected] UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
