Hi there!

I've got three questions. I already know answers for them but I'm unsure if these answers are right. Though I will not say what answers I think of.

First question is about 'malloc' and 'new' difference:
It is not about difference of "... new calls constructor and malloc does not...".
Simplificated, OS has its memory map with flags for each block saying is it free or not. Does 'malloc' and 'new' refer only to this table or they have such table (translated to OS table) for them only? Saying "for them only" means "separate table for each of 'malloc' and 'new'".

Second question:
Can compare operation on pointers (e.g. code like 'if (p1 == p2)', where p1 and p2 are pointers to different types) be reason for segmentation fault?

Third question:
I debug my application with gdb to catch a place wich calls segfault. gdb tells me 'Your app has segfaulted!' with number of line in source code. Thing is that I have very much of comments int the source saying what is to be done. When I compiled the app are commented lines counted into numeration of source code lines or not?

------- UPD:
P.S.: addition to second question:
I have output in function (a_ok) that calls function (b_bug) wich makes segfault as gdb says. But I have printf ending a newline (test_output_a) in 'a_ok' just before call to 'b_bug' and similiar test output (test_output_b) just before the line said by gdb is buggy. 'b_bug' even has test output (test_start_b), ended with newline at the begining of 'b_bug'.
Thing is: 'test_output_a' is printed. Neither 'test_output_b' nor 'test_start_b' is printed.

------- UPD2:
At some point some other application crashes. But if I put a 'printf' it appears to not crash at that point. Is there any serious reason?

Thanks in advance sorry for bad English.

malloc has nothing to do with the OS.... malloc (and free) are library calls. When a program calls malloc, malloc looks for an area on the programs heap which is large enough to hold the requested amount of memory. If it finds such a region, it will return a pointer to it. If it does not, it will call the brk() system call to ask the OS to allocate more memory to the program. All that free() does is add the allocated block to the "free list" which malloc uses. The memory is never returned to the OS until the program exits. I end up arguing with customers all the time when they state - "hey, your program has a memory leak because I show it using 1 gb of RAM when it first starts, but then it grows to 2 GB by the end of the week.". This is not a leak....

new is almost the same as malloc in that it reserves enough space for the object in memory (it probably even calls malloc under the covers. If it didn't, then calling malloc() and new() in the same program could potentially return the same chunk of memory.
The only difference I can think of is that new() might have to add a reference to the object to some list so that the garbage collector knows it can clean it up when the reference no longer exists.

Comparing two pointers will not cause a segfault.

gdb takes comments into account when printing line numbers.

1 members found this post helpful.

Thanks. That clears things enough.
Although, I already found the bug. I called free() on to mem I used later for read and write. Dunno if it is ok to read from from free()'d memory but to write is a bad thing.

Anyway, thanks.

Additionally regarding gdb, you use the 'bt' command to print a backtrace of the crash which shows which function caused it, and you use the 'l LINENUM' command to print out the lines around LINENUM.

About a_ok, might be best to show us the code for both functions.

1 members found this post helpful.

no, it is not safe at all. Probably that memory is already in use again (and it may be used by another process occasionally). In such cases the app will be died.

1 members found this post helpful.

The most common reason for segfaulting and such is a "double free." You free a pointer that was never allocated or free the same block of memory twice. Another common cause is a "stale pointer," where a pointer has a non-NULL value but it no longer points to an active block of storage. If that block has been released to the OS, a segfault can occur.

1 members found this post helpful.

Never use delete on malloc'ed resources or viceversa!

It might work for your specific situation and/or platform but at some point in time it will cause problems. Just dont mix them up.

1 members found this post helpful.

Pan,
Can you give an example of how a chunk of memory could be in use by another process after being freed? The only way I can think of is the case of a shared memory segment, but you don't use free on shared memory....

Sundial, I can't think of a way that a double free would cause a seg fault (I just tested it). A segfault happens when a program tries to access memory which is not in its memory space.
Here is an example. Setting j to point at -1 points it at the top end of the address space, then when I try to access it with printf,
it seg faults.
Geox, what is delete? I'm not familiar with that system/library call.

1 members found this post helpful.

Well, there is malloc/free and new/delete
malloc/free is the C way, new/delete the C++ way.

Well, if you have multiple threads for instance. Single threaded...no. But using memory after you free'd it is still a bad idea.


It all depends on 1) the order in which you free/alloc new and old areas, and 2) your libc or whatever lib implements your malloc/strbrk routines. But usually an allocated block of memory has some adminstration area at the end of allocated memory. If you free it twice this area most probably holds incorrect information. But, dont take my word for it. xD

And, to answer your questions:
The OS has a completely different view of memory for your application. Malloc/new only work on a small part of that, known as the heap. The heap is somewhere in memory (physical/swapped or even fragmented) but to the application it looks like one contiguous chunk of memory. Malloc keeps its own administration inside this heap. New does the same only slightly different (really depends on the library implementing it).

Only comparing the pointers themselves, not the contents of it, cannot generate a segfault.

First off all, your app does not call segfault, segfault calls you
And yes, gdb does keep your comments in mind. Look at .lst files your compiler generates how it does that. So the line numbers in gdb are correct.

1 members found this post helpful.

hm, I wanted to show you an example, but really hard. So here are some links I found:
http://stackoverflow.com/questions/1...cess-to-the-os
and also sbrk can be called with negative parameter: https://www.gnu.org/software/libc/ma...arameters.html, also mentioned, sometimes mmap used automatically instead of malloc. (not to speak about the case when the original memory manager replaced)

But good enough to say: a freed part of the memory can be overwritten also in a single threaded app (for example in another function).

1 members found this post helpful.