I'm in the process of troubleshooting some memory problems we're having in our .NET WinForms application. I'm using SciTech's .NET Memory Profiler as well as dotTrace and they all seem to be indicting root allocations by static event handlers in the .NET Framework controls. From google'ing around, I've found reports of this here and here but this appears to be reported on the v1.1 of the .NET Framework and fixes promised for 2.0. We're running on 2.0 and we're still seeing these problems. The top 25 memory offenders that I've found all point to these static event handlers and specifically SystemEvents.UserPreferenceChanged. This guy went to great lengths to find a way to unwind these handlers. I haven't tried this yet, but I did try the workaround mentioned in the Microsoft support ticket, and none of them worked for me.
I'm well aware of the leak potential of event handlers (especially long living static handlers), but this one is almost out of my control. Anyone have any experience with this?
For really deep memory leak problems in the CLR, I find the best tool is windbg. If you can get past the cryptic syntax it's an amazingly effective debugger and leak tracker. The downside is it's not very intuitive to use and there is a very steep learning curve.
The best way to learn windbg though is by doing. Here are a couple of articles that talk about using windbg to track down a leak.
http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx
http://weblogs.asp.net/scottgu/archive/2006/02/02/437231.aspx
I don't know if WinDBG is going to help here. It sounds like this is truly a bug in the framework. Is there a way you can post a simple repro? If so, then I could dig into what the heck is going on and see if there is a workaround. Otherwise your better bet would be to open a ticket on Connect. They are pretty good about getting back to people.
If you did want to look into it with WinDBG, you could investigate what is going on the heap to see what is going on. Start looking at what the objects that are hanging around are being rooted by. My guess is that you'll see pretty much what you see in the profilers above. The tricky thing with WinDBG is it can tell you just about whatever you want - you have to know what questions you want answered going into it.
Related
Is it possible to disable / bypass Unity3D main thread check when accessing methods and fields from classes in UnityEngine and UnityEditor from other threads?
If so, what are the ways to achieve this?
Does anyone know how Unity Team have implemented this check?
(I know of, and am currently using other techniques that allow me to successfully resolve any multi-threading problems, but this question is of rather academic type :)
Please respond only with possible solutions or informations why this cannot be done.
If Unity doesn't allow you to do something on the main thread respectively not on the main thread, assume there is at least one good reason for that.
Trying to circumvent it will almost inevitably result in problems, possibly hard to debug ones because Unity is trying to protect you from doing both outright illegal things that will corrupt or crash the app (ie accessing OpenGL context from a different thread) or things that are most likely going to lead to potential issues like race conditions, deadlocks, etc.
So even if there were a way to bypass said checks, without access to the code and profound understanding of multithreaded programming in the context of that code it would be highly counterproductive, self-defeating and setting yourself up for failures and hard to debug issues if you did actually manage to bypass said checks.
Every framework comes with a set of rules to work in. If Unity is saying "this method must be called on the main thread" you just follow those rules. Especially because you don't have access to the engine source code and could prove otherwise that in this specific set of circumstances it wouldn't be a problem. And if you had the source code, you could disable the check for those specific circumstances. Still, if the framework developer(s) insist that this wouldn't be a good idea you'll better listen to them because they surely know their framework far better than anyone else.
(as at 1st June 2012)
A very simple question I would really appreciate input from others (I think we all could) who are either wondering the same or have decided to go with it (if so, any user experiences shared would be great).
I have 2 main issues which seem common on stackoverflow and on various blogs, so I know I'm not the only person experiencing them.
Occasionally my sync gets corrupted for one reason or another and the sync either fails on certain data or fails to sync altogether.
Pre populating data is essential for my app, there's no reliable way of doing this (without asking the user - which isn't reliable)
I've seen many good work arounds to both these issues but I can't help feeling that my users will encounter problems still.
I'd be really interested to learn of any experiences particularly from those that have decided to publish using iCloud and Core-Data.
iCloud has been around a while now but even on iOS 5.1.1 it doesn't seem stable enough, surely a more reliable version can't be too far away.
It is hard to answer this one without "Making statements based on opinion", but it's one worth giving partially backed up opinions on to hopefully save others some time and frustration.
My opinion is that it's just not ready. I unfortunately have an app in the wild at the moment based around CoreData + iCloud and even though we danced around a number of iCloud bugs to finally get it stable enough to pass reasonably thorough testing some users are still running into the corrupted sync states. I've spent a healthy portion of my recent life trying to make it work and am currently reluctantly reimplementing the app without Core Data. I really hope that it stabilizes soon as I genuinely like most of it.
The company I work for pretty much uses a subsonic DAL for everything we do.
I recently noticed that the domain was released.
So is subsonic dead?
The domain does seem dead. Their github repository is still online though, with most recent activity from a month ago. The author Rob has a blog but he doesn't seem to have addressed his poor domain, though he does seem to acknowledge that it hasn't seen much attention from him.
For all your info, the domain is back up (probably got lost in the flood of Rob's inbox).
I put a lot of time in Jan-Feb 2012 into fixing up all the outstanding bugs in SubSonic 2, including patching, fixing or removing a lot of the failing unit tests (there were quite a few), actioning outstanding pull requests, and generally giving it a good tune up.
I had also added an MS Access provider and an auto enum generator to it.
But SS2 is very much 'mature' now, and I can't see much happening to it apart from bug fixes. That said, now that the help resources are back up, it's still a great and complete package. If there's not much active patching, that may be because it doesn't need any.
SS3 takes the project in a very different direction. I'm happy using it, but as with all these things, I mainly concentrate on what I can do WITH it rather than the tool itself. There is a pretty big backlog of outstanding stuff on SS3, and I'm not up with or even that keen on LINQ, so not sure how I'd go trying to fix anything to do with that.
And Rob has moved on to Massive, his .NET 4 dynamic tool.
UPDATE: The actual official SubSonic site is at: subsonic.wekeroad.com
Subsonicproject.com is a secondary site previously registered by contributor Eric Kemp, fallen to domain sqatters, largely broken. I nearly fell over when Rob told me this.
YES!
Rest in peace, my old friend :(
My research shows the general question is an exceptionally popular.
And in the main there is no one solution for all phones using CLDC/MIDP framework.
I have developed an app that works on all the phones I have tested so far (mostly nokia's) but it throws an IOException on the Samsung jet S8003.
Any ideas as to how can possibly obtain a trace on this specific phone?
I can't answer specifically for your platform, but over the years I've found that the best approach to these kinds of problems is to implement some kind of tracing facility in your code so that you can see the code path that led to the exception. See the answers to this SO question for some ideas on how to accomplish this: Logging in J2ME.
The nice thing about this approach is that it makes it a lot easier to debug customer problems when they run your app on a phone model you've never heard of, especially if there's an easy way for them to enable the tracelog and have it sent to you automatically.
After years of frustration I created a tool that does what you want: http://jarrut.sourceforge.net/
It's not as easy to setup as it could be, but it comes with a working example. After you get it working you will no longer do JME stuff without it.
Any suggestion to detect flaws in VB6 components running under IIS. IIS becomes unstable and after some time enter in a state of hang. The problems occur in the most part only in the production environment. We have many modules running. Probably there are components with bugs and need to identify them.
Thanks in advance.
One thing to watch out for is multi-threading issues. VB6 components often don't play well when accessed by multiple threads.
If the client code is an ASP.NET application consider putting synchlocks around the calls to ensure that they are called sequentially.
Another sure-fire way to fubar IIS is to display a message box or initiate some other sort of user interaction. Get those MsgBox calls outa there.
Other than that... good logging helps. VB6 is pretty opaque when errors arise.
Use Debugging Tools for Windows to analyze a dump of IIS. Tess' blog is one of the best resources to learn to use WinDbg. Although she focuses on .NET debugging, most of the material is applicable to any Win32 process.