I am trying to use Visual Leak Detector in Visual Studio 2008, here is an example of the output I get:
Detected memory leaks!
Dumping objects ->
{204} normal block at 0x036C1568, 1920 bytes long.
Data: < > 80 08 AB 03 00 01 AB 03 80 F9 AA 03 00 F2 AA 03
{203} normal block at 0x0372CC68, 40 bytes long.
Data: <( > 28 00 00 00 80 02 00 00 E0 01 00 00 01 00 18 00
{202} normal block at 0x0372CC00, 44 bytes long.
Data: << E > 3C 16 45 00 80 02 00 00 E0 01 00 00 01 00 00 00
The user's guide says to click on any line to jump to the corresponding file/line of code ; I tried clicking on every line but nothing happens! What am I missing?
Did you compile your code with optimization off and debug information on? Without this, it's unlikely to be able to link the addresses to your actual source code.
It could also be that the leak is occurring in code for which it can't find the source (for example an included library).
You should use deleaker. it must help you.
Related
I'm trying to make a Windows desktop smpp client, and it's connecting and sending well, aside from a bug where an extra character (¿) is added to the end of the message content that I'm receiving on my phone.
So I'm sending "test" but my phone receives "test¿". Here's the contents of the pdu object, just before it gets sent:
size :58
sequence :2
cmd id :0x4
cmd status:0x0 : No Error
00000000 00 00 00 3a 00 00 00 04 00 00 00 00 00 00 00 02 |...:............|
00000010 00 05 00 74 65 73 74 66 72 6f 6d 00 01 01 34 34 |...testfrom...44|
00000020 37 37 37 37 37 37 37 37 37 37 00 00 00 00 00 00 |7777777777......|
00000030 00 00 00 00 05 74 65 73 74 00 |.....test.|
0000003a
I'm using this c++ smpp library as a base:
https://github.com/onlinecity/cpp-smpp
I had to make some slight changes to get it working on windows, but I don't think anything was changed that could have affected this.
Someone else ran a test using a different account on the smpp server, and their test added an # symbol instead.
Any ideas what could be causing this? Thanks!
Found the problem in the end, it was due to an option in the smpp library that defaults to true, called nullTerminateOctetStrings
It was adding the 00 to the end of the message, sound slike this was required by the SMPP 3.4 standards, but our smsc didn't like it. I suppose ideally I would fix the smsc, but that's provided by a 3rd party, so I've just switched off the null terminate instead.
Someone with a similar problem and more info here: https://www.mail-archive.com/devel#kannel.3glab.org/msg06765.html
I have a C++ windows application which has some memory leak issues. Is it possible to analyze the memory leak from the dump using NTSD ? If so please guide me how to do that ?
I have also heard that we can do it using User Mode Dump. I am not very familiar with finding leaks in windows. It is very easy in Linux with Valgrind.
Is there any other better options to check this ?
see here for details about Visual Leak Detector. I have used it on Windows.
all you do in your application is to
#include <vld.h>
and you will see a report about detected leaks in terminal when debugging your program, something like this:
---------- Block 1199 at 0x04BE1058: 136 bytes ----------
Call Stack:
d:\Foobar\FooLog.cpp (26): FooLog::getInstance
d:\Foobar\FooMain.cpp (75): FooMain::init
f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (578): __tmainCRTStartup
f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (403): WinMainCRTStartup
0x759A3677 (File and line number not available): BaseThreadInitThunk
0x770C9D42 (File and line number not available): RtlInitializeExceptionChain
0x770C9D15 (File and line number not available): RtlInitializeExceptionChain
Data:
9C 33 2D 6B 74 2A 2D 6B C8 11 BE 04 00 00 00 00 .3-kt*-k ........
00 00 00 00 70 14 BB 6C 70 14 BB 6C 00 00 00 00 ....p..l p..l....
00 00 00 00 68 14 BB 6C 68 14 BB 6C 00 00 00 00 ....h..l h..l....
00 00 00 00 6C 14 BB 6C 6C 14 BB 6C 20 12 BE 04 ....l..l l..l....
00 00 00 00 CD 00 CD CD 00 00 00 00 01 CD CD CD ........ ........
68 14 BB 6C 78 33 2D 6B 00 00 00 00 00 00 00 00 h..lx3-k ........
I've had great success tracking down memory and resource leaks with DrMemory. It works with both GCC and MSVC and it's very straight forward to use.
I am using the hexdump -C to show realtime data from a pointing device on a linux box. The information it returns is 16 bytes of hex per line. Like this:
000001b0 a9 1c fd 4e f1 2c 0f 00 01 00 3e 00 01 00 00 00 |...N.,....>.....|
000001c0 a9 1c fd 4e 0e 2d 0f 00 01 00 3e 00 00 00 00 00 |...N.-....>.....|
000001d0 a9 1c fd 4e 16 2d 0f 00 00 00 00 00 00 00 00 00 |...N.-..........|
000001e0 aa 1c fd 4e b1 9a 05 00 01 00 3d 00 01 00 00 00 |...N......=.....|
000001f0 aa 1c fd 4e ce 9a 05 00 01 00 3d 00 00 00 00 00 |...N......=.....|
00000200 aa 1c fd 4e d5 9a 05 00 00 00 00 00 00 00 00 00 |...N............|
My question is, how do I know how to translate this string to the coordinate data from the mouse pointer?
Most USB input devices conform to the USB HID specification. The Xorg evdev(4) driver should be able to Just Use nearly any pointing device.
If you're writing your own driver, libusb might be a good starting point.
you need to find what is the periodicity and the size (in bytes) of x and y coordinate
you can write a progam that calculates the frequency of the coordinates are written(while moving the device). then you have to calibrate... move the pointer and see the coordinates change... it is globally how i would have done.
Trial and error maybe? You know your screen's resolution so that may help.
You could try putting the mouse pointer in the top left corner (0, 0) and record what data you get. Hopefuly it should not change if you try and scroll further past the screen (or the data repeats). Then move it to the lower right corner and record what data you get there. Again you're hoping that the values don't change if you try scroll off the screen. Then you can look at the data, fiddle with endianess until the values look right and figure out if there's any scaling going on.
Maybe
I am currentlly on a project that requires me to load a JavaCard application Applet ( a .cap ) file to a JavaCard. Our framework is based on Visual C++ and PCSC, so we need to load the same applet to a series of JavaCards. Does anyone know how this can be processed? I mean, where should I start. Thanks!
You are correct that this is not a trivial job.
There are differences between different javacards, but generally you need to do 4 things:
initialize secure communications with the card (because many javacards are "global platform" cards they require a secure channel)
send a command saying "i wanna install an applet"
send the binary data for the applet to be installed
send a command to "instantiate" the applet after the binary data is sent
I'd recommend using the eclipse plugin to install the applet initially, because you can see the APDUs generated by the plugin to do the steps above. Once you know the APDU commands you must send to install your applet, you can directly send these commands using the PCSC interface from your C++ code to automate installation on a large number of cards.
My company makes a web browser plugin called Card Boss for doing this kind of thing (card communications via pcsc) from a browser - there's a web page you can use where you can type your own APDUs and send them to the card at the follwing URL:
https://cardboss.cometway.com/content.agent?page_name=Card+Boss+Lab
If you use our tool, your applet installation script should look something like this (note that this is a script for a JCOP card using the default jcop keys)
MESSAGE BOX Installing applets...
INIT CHANNEL 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f, 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
// INSTALL CAP:
SEND 80 E6 02 00 1D 10 A0 00 00 00 09 00 03 FF FF FF FF 89 10 71 00 01 08 A0 00 00 00 03 00 00 00 00 00 00
// LOADING CAP:
SEND 80 E8 00 00 FA C4 82 01 03 01 00 25 DE CA FF (snip, I removed a bunch
of binary data representing the cap file to shorten this post, and you might
need multiple SEND commands because of limits on the size of APDUS)
// INSTANTIATING Applet
SEND 80 E6 0C 00 1E 05 63 6F 6D 65 74 07 63 6F 6D 65 74 00 01 05 00 00 00 00 00 01 00 06 C9 04 68 2C 00 03 00 00
When you create a new MFC application, the wizard creates the following block of code in almost every CPP file:
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
and sometimes it also adds this:
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
I would like to remove this code from my CPP files if it is redundant. I am using an MFC app with C++/CLI on VS2008.
I have tried running in Debug after deleting this code from a CPP, and it seems to work fine. "new"ing variables work fine, there are no leaks, and ASSERT dialogs show the correct filename and jump to the offending line.
Can anyone tell me what it does and whether it's safe to delete it?
It is perfectly safe to delete this. It's a debugging aid; leaving it in will generate better details in the warnings in the output window of any memory leaks you have when the program exits. If you delete it, you still get the memory leak report, but just without any details about where in your source code they occurred.
On Microsoft Visual C++ 2010, I can remove the whole code and put just one #define NEW DEBUG_NEW in a header, and I still got the right memory leak reports, e.g.
Detected memory leaks!
Dumping objects ->
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {7508} normal block at 0x029B9598, 54 bytes long.
Data: < > E4 B8 C9 00 12 00 00 00 12 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {7501} normal block at 0x029B94A8, 28 bytes long.
Data: < > E4 B8 C9 00 05 00 00 00 05 00 00 00 01 00 00 00
f:\source\agent\agent\deviceid.cpp(21) : {7500} normal block at 0x029CDFC0, 8 bytes long.
Data: < > A8 95 9B 02 B8 94 9B 02
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {6786} normal block at 0x029C0D88, 160 bytes long.
Data: < G > E4 B8 C9 00 19 00 00 00 47 00 00 00 01 00 00 00
f:\source\agent\sysinfo\sysinfo.cpp(27) : {6733} normal block at 0x029B84D8, 92 bytes long.
Data: < > 00 00 00 00 00 10 00 00 00 00 01 00 FF FF FE 7F
Object dump complete.