views:

407

answers:

4

While debugging a Linux app, I found a pointer with the suspicious value 0x7c7c7c7c. Does that particular value indicate anything?

(I ask because I know from my MSVC days that in a debug build, values like 0xcdcdcdcd or 0xdddddddd would be stored into heap blocks that were uninitialized, freed, or otherwise invalid. Some people use magic values like 0xdeadbeef or 0xcafebabe in uninitialized memory. I'm guessing something in libc or elsewhere uses 0x7c7c7c7c as a magic value, but I can't find it documented.)

+1  A: 

0x7c7c = 01111100 01111100 in binary. That could be one of those "most difficult to read" bit patterns that format utilities fill unused space on hard drives with.

James Curran
+4  A: 

I don't recognize that magic number, and neither does Wikipedia. I would guess that some code in your program (or in a library you're using) is using memset() and hitting your pointer. Have you grepped your code base case-insensitively for the string "0x7c"?

Adam Rosenfield
"0x7c" is a constant used within the application, but I don't see any way that four of them would be put together.
Kristopher Johnson
How is it used as a constant? Is it every memset()'d or memcpy()'d anywhere? Do you have a buffer overflow?
Adam Rosenfield
The app never sets anything to 0x7c. It reads incoming bytes from a serial port, and there is a switch statement with a "case 0x7c:" clause. However, that part of the code is not being used, and I know we don't have any buffers filled with 0x7c characters.
Kristopher Johnson
Well there's a probable answer... the only time you'll see the value 0x7C is if you forget to initialise that pointer.
Ant P.
+2  A: 

0x7C is an ASCII pipe "|" character. You could search for writes of that character as well 124 and 0x7C as Adam suggested.

Judge Maygarden
+1  A: 

Maybe the MALLOC_PERTURB_ environment variable is set? If set, it influences how malloc() initializes the allocated memory.

oliver