SIGABRT error during alllocation of char array

Question

My program crashes on following piece od code:

  newElement->name = (char*) malloc((strlen(name) + 1) * sizeof(char));

By using debugger I get SIGABRT error and I don't know why because it stops during second iteration (first iteration goes without any problem).

I checked if

  name

has a treminating null character and it has.

Here is whole code:

element* createElement(const char* name, const char* text) {
if (name == NULL) return NULL;                             

element* newElement = malloc(sizeof(element));
    if (newElement == NULL) return NULL;                    

    newElement->name = (char*) malloc((strlen(name) + 1) * sizeof(char));
    if (newElement->name == NULL) return NULL;
    strcpy(newElement->name, name);

if (text == NULL) newElement->text = NULL;
else
{
    newElement->text = malloc((strlen(text) + 1) * sizeof(char));
        if (newElement->text == NULL) return NULL;
    strcpy(newElement->text, text);
}

newElement->parentNode = NULL;
newElement->previousSibling = NULL;
newElement->nextSibling = NULL;
newElement->firstChild = NULL;
newElement->lastChild = NULL;

return newElement;

}

What do you expect anyone here to do about it? Either `name` isn't valid and so it crashes in `strlen` or the malloc arena is corrupted and so it crashes there, or `newElement` isn't valid so it crashes when you dereference it ... we have no way to know because you have provided so little info. — Jim Balter, Apr 14 '13 at 23:40
"Here is whole code" -- The whole code would include the caller, and the definition of element, at least. Please provide a SSCCE (http://sscce.org/). — Jim Balter, Apr 15 '13 at 00:07

score 0 · Answer 1 · answered Apr 14 '13 at 23:38

0

Your code by itself is totally fine.

The sigabort may result from a heap overflow, i.e., you run out of memory for your malloc.

answered Apr 14 '13 at 23:38

Elmar Peise

14,014
3
21
40

But when I run out of memory for my malloc shouldn't it give me a NULL pointer? – Martin Vrábel Apr 14 '13 at 23:42
This is the second "answer" to mention "heap overflow", but there's no such thing. If the heap is exhausted, `malloc` will return NULL. – Jim Balter Apr 14 '13 at 23:45
@Supermartzin See my comment under your question for the three possible reasons for this getting a SIGABRT. You're running under the debugger, you can figure out which one ... all we can do is guess. – Jim Balter Apr 14 '13 at 23:46
http://stackoverflow.com/questions/3413166/when-does-a-process-get-sigabrt-signal-6/3413215#3413215 – Mppl Apr 14 '13 at 23:54

Mppl · Answer 2 · 2013-04-15T00:28:21.477

0

You're trying to malloc a certain portion of memory given by the expression:

(strlen(name) + 1) * sizeof(char)

Probably you problem is with the strlen(name) part. Maybe name doesn't have a null terminated string and therefore strlen doesn't work.

As pointed out in the comment's the malloc itself isn't supposed to create and heap overflow but, it may indeed call abort() if it detects some internal data corruption which may and probably are caused by and heap overflow, buffer overflow or a leak in any other part of the code not directly related to this code. The important thing here is: does this malloc call return? or does it send the signal during execution?

If it doesn't return and it sends SIGABRT during execution you may have an hard time trying to figure out where in your program have you corrupted data structures necessary for malloc... If you're saying that the first malloc call you do executes with no problem maybe you should look at what code is executed in between but I believe that you can't be sure about the corruption happening in between the two malloc calls, malloc may simply don't see the corruption at the first execution for various reasons...

edited Apr 15 '13 at 00:28

answered Apr 14 '13 at 23:39

Mppl

941
10
18

Passing too large a value to `malloc` will cause it to return NULL, not produce SIGABRT. See my comment above for the possible causes. – Jim Balter Apr 14 '13 at 23:44
it does return null and it does call abort() which sends SIGABRT. (http://stackoverflow.com/questions/3413166/when-does-a-process-get-sigabrt-signal-6/3413215#3413215) – Mppl Apr 14 '13 at 23:51
"For example malloc() will call abort() if its internal structures are damaged by a heap overflow" this means that malloc() may indirectly send and SIGABRT due to for example internal structures corruption, so therefore if the SIGABRT is sent after a malloc instruction this may be the cause. – Mppl Apr 14 '13 at 23:59
1

You're just repeating yourself (or rather, someone else) and paying no attention to what I wrote. "SIGABRT is sent after a malloc instruction" -- `malloc` isn't an "instruction". The SIGABRT would happen *inside* `malloc`, not "after" ... but calling `malloc` with a large value *is not corruption*. – Jim Balter Apr 15 '13 at 00:00
-_-' I'm paying attention indeed what I said is still true. malloc may for some reason related to an heap overflow (internal data structures corruption if you like) indirectly send SIGABRT, therefore the malloc may be the cause of the SIGABRT. That all I'm saying... And no one told me that malloc did even return... – Mppl Apr 15 '13 at 00:05
You're totally right about one thing: this particular malloc call if it returns cannot create an heap overflow by itself. – Mppl Apr 15 '13 at 00:10
"no one told me that malloc did even return" -- You wrote "it does return null and it does call abort()" ... it can't do both. – Jim Balter Apr 15 '13 at 00:12
I said to things in that sentence, might have been misinterpreted: 1st you're right malloc returns null if you try to allocate to much space, 2nd it may indeed call abort(). But I never said this particular malloc call returns. How would I know? – Mppl Apr 15 '13 at 00:15
The edit mentioning buffer overflow in another part of the program is a definite improvement ... +1. And I was wrong about SIGABRT; it is always due to an explicit call to `abort()`, so I've deleted that comment. – Jim Balter Apr 15 '13 at 00:20
It seems that malloc call returns properly, SIGABRT occurs immediatedly after that. – Martin Vrábel Apr 15 '13 at 08:34
Wrong, it doesn't allocate properly and crash probably during allocating. – Martin Vrábel Apr 15 '13 at 08:47

score 0 · Accepted Answer · answered Apr 15 '13 at 00:17

From

http://linux.die.net/man/3/malloc

If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic message is printed on stderr; if set to 2, abort(3) is called immediately; if set to 3, a diagnostic message is printed on stderr and the program is aborted.

So you're getting a SIGABRT because you have MALLOC_CHECK_ set to 2 or 3. If it's 2, change it to 3 to get a diagnostic message.

SIGABRT error during alllocation of char array

3 Answers3