I am trying to disable power management in Linux for Zynq Ultrascale devices. Looking at the kernel, it is enabled by default. When I set CONFIG_PM=n and build the kernel, it doesn't take effect. Also I wish to know if there is any dependency on other mdoules like CONFIG_SUSPEND ?
I tried disabling both of the above parameters by setting CONFIG_PM=n and CONFIG_SUSPEND=n in my kernel.cfg. But it throws out a big blob of error which is very difficult for me as a entry level embedded linux engineer to understand. Can someone shine some light on this.
Edit:
Based on the suggestion from #sawdust. I tried to do the kernel changes using menuconfig. Then the petalinux-build breaks. I am a newbie and it is a bit difficult to understand from the log, why it breaks.
Will be great to have some experienced eyes look over the build log and suggest why it fails.
https://gist.github.com/cody70b/b866dce72ae7080981edbc2ffbc4f8e9
Hi I am student programmer using Qt to build some editing applications for work and I'm hitting an issue in my debugging practices that I am not sure how to approach. I have QTableWidget that takes at least 10 secs to fill when 100+ rows are brought in.
I am wondering if Qt's debugger has any tools to help pinpoint where the operation is taking the most of its time at. I have looked over the operation several times and everything looks right and efficient so I am left pretty lost. I have looked over the debugging and analyzing sections of the debugger and didn't see anything that looked helpful as I'm pretty sure my symptoms aren't that of a memory leak. Thanks for reading my post and thanks in advance for any help in this issue.
If you are having performance issues and want to see where in your application time is spent you need to do some Profiling. Depending on your platform and chosen IDE the tools differ and you should look into what is most commonly used.
For Linux there are few tools to pick from. One I found quite helpful is the Valgrind tool Callgrind, there is a quite nice visualizer for it called KCachegrind that should be available in your distributions repository.
Since you are using Qt there is a real possibility that you also use Qt Creator then I found something on the integration of Valgrind in Qt Creator.
could anyone suggest a way (other than using Task Manager) to track and log a program's usage of CPU and RAM in order to profile its performance?
I'm working under Windows.
Something generic would be useful. A more specific request solution would involve Visual Studio. I've tried Performance Wizard, but it doesn't seem to give me the information I need. Thanks
Process Explorer can be useful.
You can use perfmon utility to gather various counters
Well, there are published APIs for that sort of thing. You might want to take a look at WMI and the Win32_Process class.
If you're looking for a command-line program that gets those things for you there is tasklist and wmic. You can parse their output if you're so inclined.
The Microsoft Platform SDK includes the Windows Performance Toolkit, which tracks CPU, disk, and memory usage over time (along with a ton of other features). It's very handy for tracking down spikes of CPU/memory usage, as well as tracking down issues like why your laptop won't sleep.
How about Intel VTune?
I view the measuring of performance, and the finding of performance problems so as to make the program faster, as two distinctly different goals.
For measuring, one can use profilers, or simply timers, to get the job done.
For finding performance problems, I take an entirely different approach.
I am trying to help a client with a problem, but I am running out of ideas. They have a custom, written in house application that runs on a schedule, but it crashes. I don't know how long it has been like this, so I don't think I can trace the crashes back to any particular software updates. The most unfortunate part is there is no longer any source code for the VB6 DLL which contains the meat of the logic.
This VB6 DLL is kicked off by 2-3 function calls from a VB Script. Obviously, I can modify the VB Script to add error logging, but I'm not having much luck getting quality information to pinpoint the source of the crash. I have put logging messages on either side of all of the function calls and determined which of the calls is causing the crash. However, nothing is ever returned in the err object because the call is crashing wscript.exe.
I'm not sure if there is anything else I can do. Any ideas?
Edit: The main reason I care, even though I don't have the source code is that there may be some external factor causing the crash (insufficient credentials, locked file, etc). I have checked the log file that is created in drwtsn32.log as a result of wscript.exe crashing, and the only information I get is an "Access Violation".
I first tend to think this is something to do with security permissions, but couldn't this also be a memory access violation?
You may consider using one of the Sysinternals tools if you truly think this is a problem with the environment such as file permissions. I once used Filemon to figure out all the files my application was touching and discovered a problem that way.
You may also want to do a quick sanity check with Dependency Walker to make sure you are actually loading the DLL files you think you are. I have seen the wrong version of the C runtime being loaded and causing a mysterious crash.
Depending on the scope of the application, your client might want to consider a rewrite. Without source code, they will eventually be forced to do so anyway when something else changes.
It's always possible to use a debugger - either directly on the PC that's running the crashing app or on a memory dump - to determine what's happening to a greater or lesser extent. In this case, where the code is VB6, that may not be very helpful because you'll only get useful information at the Win32 level.
Ultimately, if you don't have the source code then will finding out where the bug is really help? You won't be able to fix it anyway unless you can avoid that code path for ever in the calling script.
You could use the debugging tools for windows. Which might help you pinpoint the error, but without the source to fix it, won't do you much good.
A lazier way would be to call the dll from code (not a script) so you can at least see what is causing the issue and inspect the err object. You still won't be able to fix it, unless the problem is that it is being called incorrectly.
The guy of Coding The Wheel has a pretty interesting series about building an online poker bot which is full of serious technical info, a lot of which is concerned with how to get into existing applications and mess with them, which is, in some way, what you want to do.
Specifically, he has an article on using WinDbg to get at important info, one on how to bend function calls to your own code and one on injecting DLLs in other processes. These techniques might help to find and maybe work around or fix the crash, although I guess it's still a tough call.
There are a couple of tools that may be helpful. First, you can use dependency walker to do a runtime profile of your app:
http://www.dependencywalker.com/
There is a profile menu and you probably want to make sure that the follow child processes option is checked. This will do two things. First, it will allow you to see all of the lib versions that get pulled in. This can be helpful for some problems. Second, the runtime profile uses the debug memory manager when it runs the child processes. So, you will be able to see if buffers are getting overrun and a little bit of information about that.
Another useful tool is process monitor from Mark Russinovich:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
This tool will report all file, registry and thread operations. This will help you determine if any you are bumping into file or registry credential issues.
Process explorer gives you a lot of the same information:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
This is also a Russinovich tool. I find that it is a bit easier to look at some data through this tool.
Finally, using debugging tools for windows or dev studio can give you some insight into where the errors are occurring.
Access violation is almost always a memory error - all the more likely in this case because its random crashing (permissions would likely be more obviously reproducible). In the case of a dll it could be either
There's an error in the code in the dll itself - this could be something like a memory allocation error or even a simple loop boundary condition error.
There's an error when the dll tries to link out to another dll on the system. This will generally be caused by a mismatch between dll versions on the machine.
Your first step should be to try and get a reproducible crash condition. If you don't have a set of circumstances that will crash the system then you cannot know when you have fixed it.
I would then install the system on a clean machine and attempt to reproduce the error on that. Run a monitor and check precisely what other files (dlls etc) are open when the program crashes. I have seen code that crashes on a hyperthreaded Pentium but not on an earlier one - so restoring an old machine as a testbed may be a good option to cover that one. Varying the amount of ram in the machine is also worthwhile.
Hopefully these steps might give you a clue. Hopefully it will be an environment problem and so can be avoided by using the right version of windows, dlls etc. However if you're still stuck with the crash at this point with no good clues then your options are either to rewrite or attempt to hunt down the problem further by debugging the dll at assembler lever or dissassembling it. If you are not familiar with assembly code then both of these are long-shots and it's difficult to see what you will gain - and either option is likely to be a massive time-sink. Myself I have in the past, when faced with a particularly low-level high intensity problem like this advertised on one of the 'coder for hire' websites and looked for someone with specialist knowledge. Again you will need a reproducible error to be able to do this.
In the long run a dll without source code will have to be replaced. Paying a specialist with assembly skills to analyse the functions and provide you with flowcharts may well be worthwhile considering. It is good business practice to do this sooner in a controlled manner than later - like after the machine it is running on has crashed and that version of windows is no longer easily available.
You may want to try using Resource Hacker you may have luck de-compiling the in house application. it may not give you the full source code but at least maybe some more info about what the app is doing, which also may help you determine your culrpit.
Add the maximum possible RAM to the machine
This simple and cheap hack has work for me in the past. Of course YMMV.
Reverse engineering is one possibility, although a tough one.
In theory you can decompile and even debug/trace a compiled VB6 application - this is the easy part, modifying it without source, in all but the most simple cases, is the hard part.
Free compilers/decompilers:
VB decompilers
VB debuggers
Rewrite would be, in most cases, a more successful and faster way to solve the problem.
I have a big application written in Visual Basic 6 and I need to profile it.
Is there something like ANTS Profiler but for COM applications?
I used to use VBWatch. I had a good experience with it and it helped me nail down and resolve some pesky performance problems
Have a look at VTune from Intel it has native profiling as well.
If you're having problems using VTune try AQTime profiler from AutomatedQA instead.
GlowCode is another good tool. I've used it successfully with VB6. The nice part is that you don't need to instrument or recompile your code. All you need is the symbols (.pdb file) that VB6 can already create for you.
Better late than never? VB6 has a "pause" button, right? Not only is it free, and requires no installation, but in my opinion it is by far the best tool for locating performance problems.
AutomatedQA
That's your best bet.