Tagged: Handle Leak
We’ve always observed OpenSync to have a severe handle leak in OSRunner.exe. We’ve had to work around this by scheduling to kill and restart it on a daily basis so the handle count doesn’t grow out of control (into the hundreds of thousands or more). I think this also occurs in OSConfig3.exe if left opened or used to launch jobs, but I’m not positive on that one. Definitely OSRunner.exe though.
According to Process Explorer, the handle type is Semaphore and it alternates between opening more and more handles of the following without ever closing them:
The job we are running is opening a Quickbooks Enterprise 18 file directly on the server that is in multi-user mode and synchronizing with Microsoft SQL server 2012 which also resides on the same machine. The operating system is Windows Server 2012 R2. I just updated to the latest release of OpenSync 3.0.25 with no change in behavior.
This is a fairly consistent thing and easy to monitor through task manager or Process Explorer for us. I’m wondering if this is a known problem that has a fix or if this is a bug that needs to be addressed. I can’t believe nobody else has run into this problem, but it rapidly sticks out like a sore thumb in our monitoring systems.
Am I literally the only person that sees this problem in our environment? Can anyone else validate this serious handle leak? We’re running on a 64 bit platform, but if this ran on a 32 bit platform, the handle leak would clearly exhaust paged and non-paged pool memory crashing the OS. Having high handle counts like this isn’t desirable for several reasons and should be easily fixable, I think.
Bump… Is this the wrong way to get support for OpenSync?
Support is very slow for this product.
But… no you’re not the only person with this issue.
See the following post:
Yudel, can you assist here? Since we also have the same issue?
In my experience, I don’t even have to run anything. I just open the Open Sync Configuration application and I see the OSConfig3.exe process leaking handles at a rate of about 9 per second. OSRunner does the same. Just open up task manager and add the handle column and watch it continually increment. I think there’s a loop that’s reading the configuration, and maybe checking the state of the scheduler or something. I’m not a developer, but I’m fairly technical. I found the following info about this but am not sure if it’s applicable.
Yudel. This is good information. Are you available to work on this problem?
I know that is a good info Mark. But that us the way that Tom programmed the semaphore and I cannot change that. The only way, will be to have a completely new version of OpenSync, I mean including the dlls. Sorry for the inconveniences.
What language is opensync written in? I own a software development company and I would be interested in taking a look at the code to see about fixing the problem.
thanks. but we aren’t sharing the source code.
Well, I’m not asking for a share per say. I would gladly sign NDA/etc and work on it as a contractor. It’s your app, and your source code. I’m not interested in a freebie.
It sounds like you perhaps lost a developer and are unable to fix the issue as of current? I’m offering immediate services to do so. Not necessarily for a fee, depending on your flexibility. I’m up for barter as well.
Based on vabello’s findings it sounds like a straight forward fix and I would be definitely interested in pitching in because we run into this issue daily, and I’m sure everyone else does as well. It makes using the application quite a pain, especially with the current error handling.
We can take this to a private message if you’re interested in next steps.
thanks, Mark. But We are working on a new version.
For those struggling with the handle leak maybe this method will be of some use to you. I’ve found it to be VERY reliable.
I believe I am having the same issue. My sync pegs one processor to 90% for a half hour. Scott’s link above doesn’t go to a new article. Please let me know where I should look for a solution until the software is updated.
You must be logged in to reply to this topic.