Devpartner reports GROOVEEX.DLL Leak exiting program - devpartner

I'm using DevPartner 10.6.424.1 on x64 side, I see the huge leak in Grooveex.dll, i don't directly use this dll, i'm also seeing lots of false positive leaks. Anyone have experienced?, it is because devpartner is not good for x64 side?, any feedback is greatly appreciated.
Thanks

Well, I'm one of the developers on BoundsChecker. Could you bottle up a small example of this problem? Then I might be able to test it under my microscope. Other than that, I could only suggest you try our latest build . . . though that would require you to upgrade your license to 11.0.
The product has not been static: we have resolved quite a few issues since build 10.6.424.1, though I cannot guarantee we will have resolved your particular issue.

Related

S71200 LSQL-Microsoft, Datatype changed, after copying Function Block - How do I fix this?

I am integrating SQL-Connection to one or our existing Siemens S7-1200 PLCs right now.
After copying a Function Block from a working project, one of the data types has changed and is causing trouble now.
Original:
Copied FB:
Does anybody know, how to fix this?
Someone in the Siemens-Forum could answer my question right away.
Leaving his answer here for the next person with my problem :
With the introduction of the OUC library in version V4.x, the TCON instruction, among other things, has changed. Try to update the program on the CPU. In this case, the prerequisite is that the CPU must have at least firmware version V4.1. There is also the risk that translation errors will occur in other places where the older versions were previously used. In this case, the PLC code would have to be adjusted accordingly.

Reference not found after switching from Debug to Release mode

I have a problem with several references in my VB.NET project.
For example I have this line of code:
Dim m As New Chilkat.Email
It comes from the library "ChilkatDotNet45.dll".
When I click on "References" and locate this dll, I can see that it has the settings "Use local copy" and "Do not include interop types".
When I switch to Release mode, the compiler tells me that "Chilkat.EMail" is not defined.
I have this problem with several DLLs, so it is not specific to Chilkat.
Can somebody tell me what I did wrong?
Thank you.
One of the standard approaches to solving any programming-related issue is trying to reduce the scope of the investigation. If you have a big project, in which something doesn't work, try to create a smaller project, and try to replicate desired functionality in it. Reduce as much as possible, down to a brand new project with maybe 5-10 lines of code in it.
If you were unable to solve your problem after making a reduced test case, now it's good time to post it on StackOverflow. I am usually reducing problems while writing a question on SO (not before, as one might think), constantly thinking "ok, is it minimized enough"; and this is how 90% of the questions never get posted - I often find a solution along the way of reducing my question to bare bones. :)
In your case, can you build a simplified project which has this problem and post a link here? We could then try switching Debug to Release on our machines and see if the we can reproduce. There are too many options to do the guesswork.

Intellij Idea: Continuously asking for memory increase

My intellij idea is running very slow and keeps asking for more memory even when I have given it more than 4 GB. How do I get rid of this problem?
Clean the system cache in IntelliJ Idea. This helps if you have been running the same instance of Idea for lots of projects with lots of different libraries...
I removed the ~/.IntellijIdea* folder that contained all the config and other information. This worked for me. Not sure if there is a simpler solution.

How can I find total number of warnings in project?

I've just converted a project from .net 1.1 to 3.5, and I'm being given loads of warnings in the error list.
The program compiles and runs ok, but I think I should probably try to at least reduce this large number of warnings.
The trouble is that the error list only tells me about the first 102 warnings. Even when I fix one, the number stays at 102. So I have absolutely no idea how many warnings there actually are.
If there are 150, I'd like to get rid of them. But if there are 10,000, I don't have the time to fix them all.
Is there a way to see the actual total number of warnings?
Was already answered here on the board:
Is there a way to show ALL the compiler warnings in Visual Studio 2010?
I had the same Problem.. i can only suggest to outcomment large blocks and enable them step by step. So you have a quick overview on the real number of Warnings
Though this information relates to the error messages, I think it holds true for the warnings also. The answer seems to be: NO.
It was "no" in 2006 and it is still true for VS 2010:
Provide configurable maximum error messages limit for VB.Net compiler
Thanks for the feedback on this issue. We agree that this is something that we would like to improve as we get this feedback a lot from customers who are upgrading their projects or trying to configure them on a new machine. We actually performed some experiments where we did this but it made the performance of the IDE too slow because of the overhead of tracking all of the errors. I'm resolving this issue as "Won't Fix" for now but we will likely revisit this in a future version of Visual Studio.

Updating to PHP 5.3 with deprecated functions warning disabled

I'm very keen to update a number of our servers to PHP 5.3. This would be in readiness for Zend Framework 2 and also for the apparent performance updates. Unfortunately, i have large amounts of legacy code on these servers which in time will be fixed, but cannot all be fixed before the migration. I'm considering updating but disabling the deprecated function error on all but a few development sites where i can begin to work through updating old code.
error_reporting(E_ALL ^ E_DEPRECATED);
Is there any fundamental reason why this would be a bad idea?
Well, you could forget that you set the flag and wonder why your application breaks in a next PHP update. It can be very frustrating to debug an application without proper error reporting. That's one reason I can think of.
However, if you do it, document it somewhere. It can save you a couple of hours before you remember setting the flag at all.
If you haven't already you should read the migration guide with particular focus on Backward Incompatible Changes and Removed Extensions.
You have bigger issues than deprecation. Ignoring E_DEPRECATED will not suffice. Because of the incompatible changes there will also be other type of errors or, maybe, even worse, unexpected behaviors.
Here's a simple example:
<?php
function goto($line){
echo $line;
}
goto(7);
?>
This code will work fine and output 7 in PHP 5.2.x but will give you a parse error in PHP 5.3.x.
What you need to do is take each item in that guide and check your code and update where needed. To make this faster you could ignore the deprecated functionality in a first phase and just disable error reporting for E_DEPRECATED, but you can't assume that you will only get some harmless warnings when porting to another major PHP branch.
Also don't forget about your hack and fix the deprecated issues as soon as possible.
Regards,
Alin
Note: I tried to answer the question from a practical point of view, so please don't tell me that ignoring warnings is bad. I know that, but I also know that time is not an infinite resource.
I presume you have some kind of test server? If not, you really should set one up and test your code in PHP 5.3. If your code is thoroughly Unit Tested, testing it will take seconds, and fixing it will be fairly quick too, as the unit tests will tell you exactly where to look. If not, then consider making Unit Testing it all a priority before the next release, and in the meantime go through it all, first with E_DEPRECATED warnings disabled and fix anything which comes up, then with it re-enabled once you have time. You could also run a global find-and-replace for easier to fix errors.