I recently upgraded our projects from VS2010 to 2019 which works pretty well, but hen runningit under the Debugger I get a lot of memoryleaks on finish.
Of course they where not there in VS2010.
All of my sources are build with
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
But the dump of the leaks kinda looks like this:
[16300] Detected memory leaks!
[16300] Dumping objects ->
[16300] {64582}
[16300] normal block at 0x06210D00, 16 bytes long.
[16300] Data: < z z > FC 8B AD 7A 18 8C AD 7A 01 00 00 00 80 DC 1C 06
[16300] {64581}
[16300] normal block at 0x06210E00, 16 bytes long.
[16300] Data: < z z 0 > FC 8B AD 7A 18 8C AD 7A 01 00 00 00 30 D5 1C 06
[16300] {64580}
[16300] normal block at 0x062109C0, 16 bytes long.
[16300] Data: < z z > FC 8B AD 7A 18 8C AD 7A 01 00 00 00 E8 CB 1C 06
[16300] {64579}
[16300] normal block at 0x06210780, 16 bytes long.
[16300] Data: < z z > FC 8B AD 7A 18 8C AD 7A 01 00 00 00 90 C6 1C 06
This continues for about 5700 mor lines ;-(
I already checked memory- and handle-consumtion: both are ok.
I tried to use tools like MemPro (says no leaks), Dr. Memory (crashes) and Visual leak detector, which says
[16300] No memory leaks detected.
[16300] Visual Leak Detector is now exiting.
after the leaks-dump ...
Is it likly that I had the leaks in VS2010 already but they where not found/reportet? I don't think so?
So are there any hints to start searching for it?
Is it likly that I had the leaks in VS2010 already but they where not
found/reportet? I don't think so?
So are there any hints to start searching for it?
Since VS2017, VS has a decent memory analysis tool which can be used to find memory leaks.
When you debug your project in VS2019(remember to set a breakpoint), open Debug --> Windows --> Show Diagnostic Tools--> pick memory usage
Then debug the code, when the breakpoint is hit, click Take snapshot on the Memory Usage window.
After that, you can click on the icon to enter into the analysis of the memory and you can find the problem.
You can also refer to one official document and two official document to get the tips.
=========================================
Besides,you can also use the CRT library to find memory leaks.
DeLeaker did the trick and helped my finding the Leaks. After all I found some .cpp-files, that had NOT set #define new DEBUG_NEW. After fixing that, finding the problem was quite easy. Thank you for your help, Artem Razin
Related
After some mucking about, I have got a pybluez script to connect to an AVRCP profile on various devices, and read the responses.
Code snippet:
addr="e2:8b:8e:89:6c:07" #S530 white
port=23
if (port>0):
print("Attempting to connect to L2CAP port ",port)
socket=bluetooth.BluetoothSocket(bluetooth.L2CAP);
socket.connect((addr,port))
print("Connected.")
while True:
print("Waiting on read:")
data=socket.recv(1024)
for b in data:
print("%02x"%b,end=" ")
print()
socket.close()
The results I'm getting when I press the button on the earpiece are as follows:
Attempting to connect to L2CAP port 23
Connected.
Waiting on read:
10 11 0e 01 48 00 00 19 58 10 00 00 01 03
Waiting on read:
20 11 0e 00 48 7c 44 00
Waiting on read:
30 11 0e 00 48 7c 46 00
Waiting on read:
40 11 0e 00 48 7c 44 00
After careful reading of the spec, it looks like I'm seeing PASSTHROUGH commands, with 44 being the "PLAY" operation command, and 46 being "PAUSE" (I think)
I don't know what the 10 11 0e means, apart from the fact that the first byte appears to be some sort of sequence number.
My issue is threefold:
I don't know where to find a list of valid operation_ids. It's
mentioned in the spec but not defined apart from a few random
examples.
The spec makes reference to subunit type and Id, (which would be the
48 in the above example) again without defining them AFAICT.
There is no mention of what the leading three bytes are. They may
even be part of L2CAP and nothing directly to do with AVRCP, I'm not
familiar enough with pybluez to tell.
Any assistance in any of the above points would be helpful.
Edit: For reference, the details of the AVRCP spect appears to be here: https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=119996
The real answer is that the specification document assumes you have read other specification documents.
The three header bytes are part of the AVCTP transport layer:
http://www.cs.bilkent.edu.tr/~korpe/lab/resources/AVCTP%20Spec%20v1_0.pdf
In short:
0: 7..4: Incrementing transaction id. 0x01 to 0x0f
3..2: Packet type 00 = self contained packet
1 : 0=request 1=response
0 : 0=PID recognized 1: PID error
1-2: 2 byte bigendian profile id (in this case 110e, AVRCP)
The rest is described in the AVRCP profile doc, https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=119996
I don't find the documentation to be amazingly clear.
I have provided a sample application which seems to work for most of the AVRCP devices I have been able to test:
https://github.com/rjmatthews62/BtAVRCP
I want to do a statistic of memory bytes access on programs running on Linux (X86_64 architecture). I use perf tool to dump the file like this:
: ffffffff81484700 <load2+0x484700>:
2.86 : ffffffff8148473b: 41 8b 57 04 mov 0x4(%r15),%edx
5.71 : ffffffff81484800: 65 8b 3c 25 1c b0 00 mov %gs:0xb01c,%edi
22.86 : ffffffff814848a0: 42 8b b4 39 80 00 00 mov 0x80(%rcx,%r15,1),%esi
25.71 : ffffffff814848d8: 42 8b b4 39 80 00 00 mov 0x80(%rcx,%r15,1),%esi
2.86 : ffffffff81484947: 80 bb b0 00 00 00 00 cmpb $0x0,0xb0(%rbx)
2.86 : ffffffff81484954: 83 bb 88 03 00 00 01 cmpl $0x1,0x388(%rbx)
5.71 : ffffffff81484978: 80 79 40 00 cmpb $0x0,0x40(%rcx)
2.86 : ffffffff8148497e: 48 8b 7c 24 08 mov 0x8(%rsp),%rdi
5.71 : ffffffff8148499b: 8b 71 34 mov 0x34(%rcx),%esi
5.71 : ffffffff814849a4: 0f af 34 24 imul (%rsp),%esi
My current method is to analyze file and get all memory access instructions, such as move, cmp, etc. Then calculate every access bytes of every instruction, such as mov 0x4(%r15),%edx will add 4 bytes.
I want to know whether there is possible way to calculate through machine code , such as by analyzing "41 8b 57 04", I can also add 4 bytes. Because I am not familiar with X86_64 machine code, could anyone give any clues? Or is there any better way to do statistics? Thanks in advance!
See https://stackoverflow.com/a/20319753/120163 for information about decoding Intel instructions; in fact, you really need to refer to Intel reference manuals: http://download.intel.com/design/intarch/manuals/24319101.pdf If you only want to do this manually for a few instructions, you can just look up the data in these manuals.
If you want to automate the computation of instruction total-memory-access, you will need a function that maps instructions to the amount of data accessed. Since the instruction set is complex, the corresponding function will be complex and take you a long time to write from scratch.
My SO answer https://stackoverflow.com/a/23843450/120163 provides C code that maps x86-32 instructions to their length, given a buffer that contains a block of binary code. Such code is necessary if one is to start at some point in the object code buffer and simply enumerate the instructions that are being used. (This code has been used in production; it is pretty solid). This routine was built basically by reading the Intel reference manual very carefully. For OP, this would have to be extended to x86-64, which shouldn't be very hard, mostly you have account for the extended-register prefix opcode byte and some differences from x86-32.
To solve OP's problem, one would also modify this routine to also return the number of byte reads by each individual instruction. This latter data also has to be extracted by careful inspection from the Intel reference manuals.
OP also has to worry about where he gets the object code from; if he doesn't run this routine in the address space of the object code itself, he will need to somehow get this object code from the .exe file. For that, he needs to build or run the equivalent of the Windows loader, and I'll bet that
has a bunch of dark corners. Check out the format of object code files.
I am trying to use a Bluetooth ELM327 wireless OBD-II receiver to obtain data from a vehicles OBD-II port. I am not trying to gather information about the engine, but rather some of the electronics in the vehicle. I have been given certain commands to access the devices and have been successful using different devices and software other than the ELM327.
I do not have much experience dealing with the CAN bus and data transfer in general; so forgive me if I am leaving out crucial pieces of this process. However, I do understand CAN basics such as message headers and data bytes.
So far I have been using the Ford DET tool to gather data from the device. I am able to send an 8 byte CAN message and receive data back. I have many commands which I need to parse proper data from the output they produce. For example, if I were to send the command
0x727 03 19 02 8F
My log file shows:
00184.3548 (Rx) 0x72F 10 0F 59 02 CA E1 00 00
00024.8556 (Rx) 0x72F 10 0F 59 02 CA E1 00 00 --- Request DTC Info: Report DTCs By Status Mask (StatusMask: 8F)
00189.4469 (Tx) 0x727 03 19 02 8F 00 00 00 00 --- Request DTC Info: Report DTCs By Status Mask (StatusMask: 8F)
00189.4549 (Rx) 0x72F 10 0F 59 02 CA E1 00 00
00189.4572 (Tx) 0x727 30 00 00 00 00 00 00 00
00189.4591 (Rx) 0x72F 21 0A E1 01 00 0A 9A 89
00189.4612 (Rx) 0x72F 22 13 0A 00 00 00 00 00 --- Pos Resp to Read DTCs By Status Mask (3 DTCs)
Here is what happens when talking to the ELM327 with goSerial. I have included all the commands to illustrate how I am using the ELM327 device.
>ath1
OK
>ats1
OK
>atal
OK
>at sh 727 <-- set the message header to 0x727
OK
>03 19 02 8f
72F 03 7F 03 11
>
As you can see, the result output on the final line is much shorter than that the Diagnostic Engineering tool is giving me. Am I not configuring the device properly?
Basically I am trying to have the ELM327 output match the output from the Ford DET tool. I understand that this is a very vague question.
Here is some other information about my configuration:
Baud rate: 38400 (standard for vehicles?)
CAN version: ISO 15765-4
All my commands start with 0x727. Flow control is transmitted with 0x727 and 0x7A7.
Also, I have already read over most of the ELM327 documentation so please do not leave that as a solution.
What makes you think that "the result output on the final line is much shorter than that the
Diagnostic Engineering tool is giving me" ?
Actually, the response of the ECU is perfectly valid:
72F 03 7F 03 11
72F - ID of the CAN message
03 - Length of data bytes
7F - Negative response
03 - The negative response is for command 03
11 - Not supported
You have an error in the line where you are sending the CAN message "03 19 02 8f".
You should send the message like this: "19 02 8f".
When monitoring DDE messages with DDESpy, I can capture what I am looking for, however DDESpy truncates it:
[1ff8:212781728] CB(Execute, fmt=0x0("?"), 39002100, c001("WWW_OpenURL") 0(""), 3d003b00, 0, 0)=3e004300
Input data=
22 00 68 00 74 00 74 00 70 00 3a 00 2f 00 2f 00 ".h.t.t.p.:././. 6e 00 65 00 77 00 73 00 2e 00 79 00 63 00 6f 00 n.e.w.s...y.c.o.
...
Now, this is truly annoying, because what I am really after are the parameters at the end of the input data (after the ....)
How could I get that data?
The location of the DDEML API is important to DDE monitoring
applications. DDEspy from Microsoft and our Dynamic Data Studio use
the DDEML APPCLASS_MONITOR facility. Message hooks can read the memory
handles of the data attached to a WM_DDE_xxx message, but for 32-bit
applications the handles have no meaning in other process spaces. The
32-bit version of the DDEML API extracts and passes some data to a
monitoring application, but only the first 28 bytes. There is no way
to obtain more than this.
Apparently this is why I am seeing only the first 28 bytes. I guess I am out of luck.
Source: http://www.angelfire.com/biz/rhaminisys/ddeinfo.html
I've been playing around with capturing the input from my keyboard device:
/dev/input/by-path/platform-i8042-serio-0-event-kbd
for me, and I was wondering if there was any specification for what it returns, using
od -tx1 /dev/input/by-path/platform-i8042-serio-0-event-kbd
to listen. I'm curious mostly due to the behavior of certain keys; the meta, arrow keys, numpad forward slash.
0520300 ac 9d 86 4c 6b 0f 04 00 04 00 04 00 (db) 00 00 00
0520320 ac 9d 86 4c 8c 0f 04 00 01 00 (7d) 00 00 00 00 00
0520340 ac 9d 86 4c 95 0f 04 00 00 00 00 00 00 00 00 00
Every other key I've looked at so far has the two bytes in parentheses as matching values, is there any reason these are special?
/dev/input/by-path/platform-i8042-serio-0-event-kbd is just a symlink to /dev/input/eventX event device file. Data can be read from event device files as
struct input_event {
struct timeval time;
__u16 type;
__u16 code;
__s32 value;
};
defined in /usr/include/linux/input.h.
Possible values of type are prefixed with EV_.
Possible values of code depend on type. They are prefixed with KEY_ or BTN_ or REL_ or so on.
Possible values of value depend on both type and code. For example for key-press events value equals 1 and for key-release events 0.
You can examine event data with:
evtest /dev/input/eventX
where X is the event device number of your keyboard (or any other event device). One key press or release normally emits three events (EV_MSC, EV_KEY and EV_SYN).
Some keys have unusual scan codes...
From: http://www.beyondlogic.org/keyboard/keybrd.htm (with edits) :
Now there's 101 keys and 8 bits make 256 different combinations, thus you only need to send one byte per key, right?
Nope. Unfortunately, a handful of the keys found on your keyboard are extended keys, and thus require two scan codes. These keys are preceded by a E0 (hex). But it doesn't stop at two scan codes either. How about E1,14,77,E1,F0,14,F0,77! Now that can't be a valid scan code? Wrong again. It's happens to be sent when you press the Pause/Break key. Don't ask me why they have to make it so long! Maybe they were having a bad day or something?