Member Avatar for niamul

/*
* Please try to answer this question. There is no time bound.
* The following C program segfaults of IA-64,
* but works fine on IA-32.
*/

int main()
{
int* p;
p = (int*)malloc(sizeof(int));
*p = 10;
return 0;
}

>/* Why does it happen so? */

/* Can any body explain to me this? I got this prob. from one of my friends. */

  • 4 Contributors
  • 7 Replies
  • 195 Views
  • 3 Days Discussion Span
  • Latest Post Latest Post by niamul

Dani AI

Generated

Most likely cause: an implicit declaration of malloc (missing prototype) leading to a truncated pointer on a 64‑bit build. On older C dialects a call to an undeclared function is assumed to return int; that hides nothing on IA‑32 (4‑byte int, 4‑byte pointers) but breaks cleanly on 64‑bit ABIs where pointers are 8 bytes. The truncated return value becomes an invalid address and dereferencing it causes the segfault.

Clarification of earlier replies: IA‑64 refers to the Itanium 64‑bit ABI and IA‑32 to 32‑bit x86. The alignment idea from is reasonable to consider for exotic allocators, but standard malloc implementations return suitably aligned blocks, so alignment is not the usual culprit here. ’s “recompile” suggestion is fine as part of the workflow, but recompiling without fixing the missing prototype won’t help. ’s hint about the proper header points to the actual fix.

Practical checklist to reproduce and fix the problem:

  • Compile with strict warnings: gcc -Wall -Wextra -std=c99 -g. Fix any implicit declaration of function 'malloc' warnings first.
  • Make sure the correct header declaring malloc is present so the compiler knows the return type.
  • Use a safe allocation idiom like p = malloc(sizeof *p) and always check the result for NULL.
  • If the crash persists, use runtime tools: valgrind ./prog or compile with AddressSanitizer gcc -fsanitize=address -g -O0 to catch heap corruption or other memory errors.

If after adding the correct prototype and following the checklist the program still fails on IA‑64, dump the pointer values and examine compiler warnings; those will quickly show any pointer-size mismatch or heap corruption.

Recommended Answers

All 7 Replies

Member Avatar for jwenting

Did you recompile it for your 64 bit architecture?
If not maybe the compiler optimised away the sizeof(int) causing malloc to allocate space for a 32 bit int.
Then when you run on a 64 bit system where the assignment would try to write a 64 bit number, boom.

Just speculation but could be worth looking into...

Member Avatar for Dave Sinkula 
#include <stdlib.h>
Member Avatar for jwenting

I'd kinda assumed it was a snippet rather than a complete source ;)

Member Avatar for Chainsaw

I don't know what IA-64 and IA-32 refer to. Is that a particular hardware standard?

Typically segfaults of this type are because your CPU demands that shorts be aligned on short boundaries, longs on long boundaries and so on. So if 'int' is 64 bits on some machine, it may need to be on a 64 bit boundary. This isn't true for all hardware, of course.

Compare Intel x86 to ARM; on x86 a long can be aligned on anything, but on ARM it must be aligned on a 4-byte boundary.

So, for the sample code provided, it isn't clear to me what is wrong unless the malloc does not return aligned data. Malloc implementations I've seen on systems that care (and most that don't) return data aligned on some large (8 or 16) byte boundary to avoid this problem.

Member Avatar for jwenting

IA-64 if I'm not mistaken is a 64 bit AMD CPU, that would make IA-32 it's 32 bit equivalent.

64 bits is 8 bytes, so if malloc returns data alligned on 4 bytes he's in trouble unless he recompiles.
Many compilers I think have compiler flags to set byte allignment.

Member Avatar for niamul

Yes jwenting,
I recompile it for my 64-bit architecture but it gives the same error.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.