Increasing the stack size of a Thread...very Urgent

[prashas_d]

Hii Alll

I am new to Threads in C. I am doing C in Unix Solaris.

In my program for creating Threads I am using the function
thr_create( NULL, 0, ThreadFunc, NULL, THR_BOUND, NULL ))
in which second argument indicates the stack size. 3rd argument
is function name in which Thread executes.

If we give it as 0 it takes default size of some bytes. In my case
I am using so many local variables of large character arrays.
so I need to increase stack size. If I am giving any other value
other than 0 as a second argument it is giving segmentation fault
in ThreadFunc().

Can anyone please suggest me How to increase the stack size of
a thread?

Thanks in advance.
prashas_d.

[Paul McKenzie]

Why do you need to create local arrays? Why not dynamically allocate using malloc()?

Instead of this:

void func()
{
    char x[100000];
/* ... */
}

Do this:

#include <stdlib.h>
void func()
{
    char *x;
    x = malloc(100000 * sizeof(char));
    //...
    free(x);
/* ... */
}

Unless the stack is extremely limited, increasing the stack size is usually a poor man's "solution" and should be used only as a last resort.

Usually the problem of stack usage can be solved by either reducing the space the local variables take up (i.e. use pointers, not arrays), or if the problem is a recursion issue, write a non-recursive version of the code.

Regards,

Paul McKenzie

[prashas_d]

Paul,

Using dynamic arrays is resulting me other problems like
segmentation fault core dump if memory allocation is failed.

for example if you check this code.


char *x;

x = (char *)malloc( 1000 ); // core dump at this place

--- statements----

free(x);

if I am calling the above function repeatedly, may be for the first 2 to 3 times
it is allocating memory and may be at 4th or 5th time it is giving core dump.
It's unreliable to use dynamic arrays. There is no other way to go other than static arrays.

Thanks for your suggestion.

prashas_d

[Vedam Shashank]

Using dynamic arrays is resulting me other problems like
segmentation fault core dump if memory allocation is failed.

Is very much advisible to check for memory allocation failures and handle them appropriately.

It's unreliable to use dynamic arrays.

If it failed it was probably because there was not enough memory left to allocate for your application (i havent come across any other reason why it could have failed).

I think it is worthwhile to mention, Your application has limited amount of memory (Usually this is HUGE ENOUGH)

Maybe you w'd like to mention what is the task that you are trying to accomplish.

[Paul McKenzie]

Paul,

Using dynamic arrays is resulting me other problems like
segmentation fault core dump if memory allocation is failed.

More than likely, the problem is with your code, not with malloc() and free(). I would bet that all malloc() and free() did was expose a bug in your existing program that you never realized you had when you used arrays (or you didn't use the memory you allocated properly).

It's unreliable to use dynamic arrays.

No, more than likely, it is your code that is unreliable.

char *x;

x = (char *)malloc( 1000 ); // core dump at this place

--- statements----

free(x);

The problem is not malloc() or free(). The problem is what you are doing with the memory you allocated (the "statements" that you did not post). For all we know, you could be doing all sorts of wrong things with the memory you allocated within those " ---- statements ----". You should post what these statements are.

You more than likely corrupted the heap with your own code, or you're writing to an out-of-bounds memory location, or you are feeding free() with an invalid pointer, etc.

Don't be surprised if you're making the same mistakes with using just arrays, but the error hasn't caused a runtime error (yet).

There is no other way to go other than static arrays.

That is very hard to believe. Are you saying that the heap manager for the compiler is buggy? If so, then no one would use malloc() or free() when using the compiler, and that sounds too unrealistic to be true.

Again, the problem is more than likely what you're doing with the memory, and not the calls to malloc and free.

Regards,

Paul McKenzie

[prashas_d]

Thanks Paul,

Thank you so much for being straight forward and giving me
the valuable suggestions.

I cannot post the statements which I am using in my code because
that includes complex business logic which may not be understandable
to others.

However I think there is no fault in my other statements in the code.
Because in the below code the core dump is comming at malloc statement
but not at other statements as I clearly mentioned as comment.

char *x;
printf("first\n");
x = (char *)malloc( 1000 ); // core dump at this place
printf("second\n");
--- statements----

free(x);

In the above code the string 'first' is getting printed and then it is giving coredump without printing string 'second' which clearly shows problem is
with malloc statement. This is why I said I am left with static arrays only.


Hope I will find a solution to increase stack size of a thread which may solve the problem.

Thanks,
prashas_d.

[JohnyDog]

In the above code the string 'first' is getting printed and then it is giving coredump without printing string 'second' which clearly shows problem is
with malloc statement. This is why I said I am left with static arrays only.

In case of memory corruption, the place of actual crash has usually no correlation to the place where the corruption really occurs. (Also, in your case you should be aware that standard IO is usually buffered, meaning the printf() message might show several lines after you called it - and if crash occurs at that time it might not show at all). Most probably there is problem with your code somewhere else and is only detected at the malloc call. If that is the case, static allocation won't help really.

[Paul McKenzie]

Thanks Paul,
I cannot post the statements which I am using in my code because
that includes complex business logic which may not be understandable
to others.

Well the problem is the complex business logic that is corrupting the heap.

However I think there is no fault in my other statements in the code.
Because in the below code the core dump is comming at malloc statement
but not at other statements as I clearly mentioned as comment.

If your program only consisted of those lines, then you are correct. The problem is that your program does not consist only of those lines.

When you corrupt the heap, it can be done in other areas of your program, probably all of that business logic that you spoke of.

Hope I will find a solution to increase stack size of a thread which may solve the problem.

No, all you're doing is masking an existing problem by doing this, not fixing it. What may end up happening is that your "array" version of the program will crash in the future, or when you run it on another machine, or if you were to add (or remove) code and rebuild the program, etc.

Since it more than likely is the business logic that is causing the error, then, as JohnyDog pointed out, your code is faulty with or without dynamic allocation.

Regards,

Paul McKenzie

[TomWidmer]

It's unreliable to use dynamic arrays.

And yet, (almost) all non-trivial C programs ever written make extensive use of malloc and free with no problems (other than coding bugs). They are only unreliable if your code has bugs in it. Calls to malloc and free are detection points for earlier heap corruption.

If you switch to static arrays, you may well switch to stack corruption, which tends to cause hard to track down bugs.

[exterminator]

Johny - the standard IO is unbuffered by default.

OP - one thing to check would be if you are losing the head pointer of the dynamic allocation somewhere due to some pointer arithmetic and hence calling free on it...

Also, if you think malloc is causing a problem - then write a small program with just the main function and allocate some memory and free it.. see if that also results in memory issues - if not, then of course, its you logic between the malloc and free that's troubling.

[Paul McKenzie]

To the OP:

For example:

#include <stdlib.h>
#include <stdio.h>
int main()
{
   int i;
   char *x;
   for ( i = 0; i < 10000; ++i )
   {
       printf("first\n");
       x = (char *)malloc( 1000 ); 
       printf("second\n");
       free(x);
   }
}

This program calls 10,000 times to malloc() and free(). This code should not crash. Compile and run this program. Does it give a segmentation fault?

Regards,

Paul McKenzie

[ScorpionChief]

@Paul McKenzie

Sir, I don't think we require cast to malloc in "C".

[exterminator]

@Paul McKenzie

Sir, I don't think we require cast to malloc in "C".

I am not Paul but why not? malloc returns void*

Also, you should check if malloc returned NULL...

[ScorpionChief]

malloc returns void*

That's the reason why it's not required in "C". Implicit pointer conversions from void* is allowed in ANSI C.

[Paul McKenzie]

That's the reason why it's not required in "C". Implicit pointer conversions from void* is allowed in ANSI C.

OK, so how does this resolve the OP's problem? The original code from the OP did have a cast, so you should direct your comment to him/her. But this is totally a non-issue with respect to the OP's problem.

Maybe the OP is using this code in a C and C++ module and is experimenting with it. The lowest common denominator that works for both C and C++ is to cast.

Regards,

Paul McKenzie