When i run a sample application of gstreamer-1.0 appsrc example code in x86 machine and imx7 sabre board, i was able to visualize memory leak in the sabre board but not able to visualize the memory leak in x86 machine. Attached code for your reference. Is this a known issue ? Any workarounds/patch available for the memory leak ?
https://www.dropbox.com/s/lctmjod1ycwzm85/appsrc_example.zip?dl=0
Related
We've QNX 7.1.0 and our application is written in CPP. We need to find out stack, heap and data segment memory usage of the current thread which is running . Is there any API or QNX command to find it?
Note: We are not launching our application through QNX Momentics IDE. Directly running our application.
Referred: How to get CPU load / RAM usage out of QNX?
but it talks about only CPU load.
Can anyone please help out?
I'm currently programming a GameBoy Classis Emulator. Here is the GitHub-repo (https://github.com/FelixWeichselgartner/GameBoy-Classic-Emulator).
The CPU instructions seem to be working fine. I compared the instructions with the ones of this gameboy debugger (http://bgb.bircd.org/). For Tetris im executing the same instructions.
My question is about the graphics. I have implemented a function that fetches the tiles from the correct address (depending on which tiles set is used). However I don't know how to initialise the Video Ram (# adress 0x8000). I copied the 32kB Tetris rom in my memory from adress 0x0000 to 0x7FFF. Therefore everything from 0x8000 is not initialised here. Neither in the Debugging tool, nor in my code is something written to the vram (from the cpu opcode instructions).
Therefore I expected I will have to initialise the VRAM. However I could not find any resources online, when something is written to VRAM.
So my question:
Which instance of a gameboy emulator is responsible for copying tiles in the VRAM.
What I have already tried:
Debugging with another emulator -> this showed me that no cpu instructions copy to VRAM.
Looking at various gameboy emulators on Github -> could'nt find anyone initialising the VRAM
I someone was able to help me I would be very thankful.
Greetings
schnauzbartS
On Gameboy Classic there's only one way to initialize VRAM - manually copy data with CPU instructions. It's game's responsibility. You can see this, for example, in bootstrap ROM:
XOR A ; $0003 Zero the memory from $8000-$9FFF (VRAM)
LD HL,$9fff ; $0004
Addr_0007:
LD (HL-),A ; $0007
BIT 7,H ; $0008
JR NZ, Addr_0007 ; $000a
On Gameboy Color there's another way to write to VRAM - DMA. But, again, game has to explicitly trigger it. Gameboy doesn't do anything on its own.
I use C++ (Visual Studio 2015) and OpenCV (ver 3.2.0) to process data sent from Kinect v1. My C++ program has no problem when it starts debugging for the first time. After it stops debugging and re-start debugging, however, it gets very slow.
I am suspecting that the program closes without releasing some memory (i.e., memory leak). I am aware of that I would need to use the delete function to release the memory if I use the new function. But I didn't use the new function in the C++ program (I neither used the malloc() function, which is equivalent to the new function in C programs).
For OpenCV, I use the destroyAllWindows function at the end of the program. For Kinect v1, I also use the NuiShutdown(), Release(), and CloseHandle() functions at the end of the program.
Is there anything else I need do to release the memory (e.g., releasing memory associated with Mat in OpenCV)? Or is something else causing the decrease in processing speed?
I'd appreciate your help. Thanks.
After first run disconnect Kinect then reconnect and try second run.
If all goes well now then the problem is most likely stuck thread. The device access is usually handled by separate threads and especially with USB they can get stuck (in case of error or sync problem between accessing form host and expecting on device side) until you disconnect device (not sure which Kinect driver are you using but JUNGO version which NuiShutdown() infers have this problem). You can also check task manager before disconnection if there are not some stuck processes left after first run.
To remedy this you need to find out what are you doing wrong during access. It could be:
wrong USB port
use the back side not front slots.
invalid USB transfer request
device is always waiting for specific set of commands or stream and waits until it does not receive it so it blocks all other things. So using unsupported commands or reading in wrong times or sizes of packets can cause this.
USB communication is out of sync
PC host can timeout in case you do not have enough CPU power while critical operation is processed (or have opened too many apps on background).
This can be caused also by wrong gfx driver as I suspect you are using rendering ... Intel HD graphics can generate such problems with ease especially on notebooks. Try to disable any rendering in your app or at least limit rendering to OpenGL 1.0 to see if speed is the same in between runs. If this is the case the whole desktop usually flickers or is not repainting parts of apps ... and animations are sometimes sluggish.
Another problem might be a debugger. If without it all is well then debugger is the problem and you can not solve it. Debugging while accessing IO can cause sync and timeout problems especially with USB.
To check for memory leaks you can simply see how much free memory you got before 1st run and compare it to values after 1st,2nd,3th .. runs if the value lowers you got something stuck somewhere. After app close all the memory belonging to app is freed by OS so even if you forget some delete that does not matter unless some thread is still running ...
Some USB drivers based on libUSB I encountered got also problem with Handle leaks. But that behaves differently ... all runs fine until there are no free handles. After that OS is non functional you can not open any window,app, anything ... until any app is closed.
[Edit1] Front USB slots
Front slots are usually connected to motherboard with relatively long cable (usually flat and not very well shielded) so it is more susceptible to noise. Also as it is located usually around HDD and above high frequency parts of the motherboard it also induce it into the USB feed. All this degrades the quality of USB signal causing much much bigger rejection rate hence lowering sync capability and also the overall usable bandwidth.
If you compare that with backside USB ports they have no cables but are connected directly in PCB with short and well shielded paths so the connection quality is much much better.
So if you use device demanding high bandwith or synchronism then front ports are a bad choice.
I have a legacy software with C++ and C# code, which worked in Windows XP SP3 and .NET 2.0 (VS2005). The software did scanning and image processing with plenty of memory intensive processing. The PC has 2gb RAM. The stack size is reserved to 15MB for the software process.
This software was migrated to .NET4 (VS2010). During the migration, code logic is not altered. The software works properly for individual scans and processing. However, for continous job runs the software crashes at random places. For all the crashes, the event viewer shows 'The software was terminated due to stack overflow'. On debugging the crash dump, it points to ntdll.dll (kernel dll).
To fix the issue following solutions were tried. None of them worked.
Stack size increased to 20MB. Software crashed.
Process is allocated 820 MB by VirtualAlloc in the beginning. This was increased to 1024 MB. It delayed the crash by a day. But eventually it crashed.
alloca was used to allocate memory for local variables. These were replaced by _malloca.
Please let me know if .NET 4 migration requires major increase in RAM to run the software without failure. Inputs on memory requirement change for .net 2 to .net 4 migration are welcome.
Does anyone know how to retrieve code from a Texas Instruments DSP processor? I'm using a TMS320LF2407 DSP, and I need to access the program on the chip, most likely using the JTAG connector. Any help would be appreciated. I've contacted TI, they were no help. I found SPRA830 that talks about using C code to copy blocks of program code to memory, but none of the associated files are available.
If you have access to the jtag then you should be able to connect to it with TI's Code Composer Studio. This also assumes that you have a supported JTAG emulator box which are fairly expensive. I think the biggest problem is going to be finding out what memory addresses are being used for code vs RAM. Can you give more details about what you're trying to do? Is this some specific hardware or is it an eval board?