struct cell_info
{
int row;
int col;
int adj_cellcount;
int clicks_to_exp_by_enemy;
int clicks_to_exp_by_me;
cell cell_to_move;
};


i am making a llist of these structure
a segmentation fault error is received on line
struct cell_info *newenemycell=(struct cell_info *)malloc(sizeof(structcell_info));


when i run this code in college no such error comes

pls suggest something

Reported to the moderators for moving to programming forums.
Also please enclose code segments in [ code ] tags if ease of reading.

If you are obtaining malloc(sizeof(struct cellInfo)) then you should not be encountering a segfault <em>unless</em> you have previously munged the stack by such sins as a "double free." We need to see a larger excerpt of your code; and please, use a code-tag.

Some error your program made earlier (such as writing past the end of a previous allocation) causes the failure there.

seg faults don't always occur at the point of the actual bug. Sometimes a bug has no immediate symptom and leads to a seg fault elsewhere.

seg fault in this line does not occur when i run the code on college's pc..
when i comment this line then seg fault occurs in the line where malloc is used next..

That it does not occur on somebody else's PC does not mean anything. That's a nasty part of segfaults; they do not necessarily show and also not where you think they happened.

Comment out the line that you posted, put some other statements there and it more than likely will crash again.

gdb is your friend and else use printf's before and after the malloc statement.

As others indicated, give us a larger part of your code.

Some earlier part of your program overwrote data malloc uses to keep track of which memory chunks are free.

Typically that means in the college's pc the same bug overwrote something that doesn't have an symptom within the execution of this simple program. The lack of a symptom doesn't imply lack of a bug.

A different version of malloc might reuse freed memory in a different pattern, so it never gets around to hitting the corrupted area within the rest of the execution of the program. Or it might store its control info a little differently relative to the allocated data in a way that delays or avoids the symptom of your bug.

But is your Linux 32 bit or 64 bit and same question for the college's pc?
If you recompiled the code from 32 bit to 64 bit, then the bug might be a portability bug that would never have any symptom in 32 bit. In 32 bit, pointers, longs, and size_t all have the same size as int. One of the most common portability bugs is code that assumes (intentionally or accidentally) that one of those other types is the same size as int.

You still need to find the section of code that overwrites memory it shouldn't. But having a guess at the nature of the problem can change the way you look for it.

An expert would first use gdb to examine the failure inside malloc to see exactly which location had been overwritten by the earlier bug, then restart with gdb and a data breakpoint to see exactly where that location is written. But that approach is too far beyond beginner level to suggest. Instead, I'll assume your whole program is short enough you could post it so someone would easily spot the bug, or you could examine it for the expected kind of bug.

That tells us very little new information. It hints (but doesn't prove) that the original bug is stable (always clobbers the same thing). We already could assume some bug had clobbered data used by malloc, so a subsequent use of malloc would trigger the symptom.

Many memory clobber bugs are unstable: An unrelated change elsewhere in the program tends to change the use or location of the memory that the bug clobbers, leading to lots of false conclusions about what "fixes" or "causes" the bug, when those unrelated changes really just hide or reveal the symptom.

But the most common memory clobber bugs, which write past the end of an allocated chunk of memory, tend to be stable. They clobber memory used by malloc, not by random accident but systematically, because memory used by malloc to keep track of used and free chunks consists of little control blocks right before and after each used chunk.

Moved: This thread is more suitable in <PROGRAMMING> and has been moved accordingly to help your thread/question get the exposure it deserves.

I think you forgot to actually move it

To the original poster: Most likely there was memory corruption somewhat earlier in the code.
I think we will need to see some more code before we can make a clear answer.

right you were ... rectified.

This

In fact, in my experience, seg faults usually don't occur at the same place as the bug that caused them. Sometimes you can overrun an array without issue, then hundreds of lines later the code will seg fault when you go to print some random variable that has nothing to do with the bug.

-fbounds-check will usually help in catching these array overrun bugs.