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

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.

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

Instead of this:

Code:

---

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

---

Do this:

Code:

---

#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

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

Quote:

---

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.

Quote:

---

It's unreliable to use dynamic arrays.

---

:cry: :cry:
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.

Quote:

---

Originally Posted by prashas_d

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).

Quote:

---

It's unreliable to use dynamic arrays.

---

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

Quote:

---

Code:

---

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).

Quote:

---

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

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.

Quote:

---

Originally Posted by prashas_d

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.

Quote:

---

Originally Posted by prashas_d

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.

Quote:

---

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.

Quote:

---

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

Quote:

---

Originally Posted by prashas_d

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.

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.

To the OP:

For example:

Code:

---

#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

@Paul McKenzie

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

Quote:

---

Originally Posted by ScorpionChief

@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...

Quote:

---

Originally Posted by exterminator

malloc returns void*

---

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

Quote:

---

Originally Posted by ScorpionChief

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

Quote:

---

Originally Posted by ScorpionChief

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

---

You are right. But still I feel it is better to be explicit about such implicit conversions.

Quote:

---

Originally Posted by Paul McKenzie

OK, so how does this resolve the OP's problem?

---

I guess pointing such things are very common in forums. There are lot of things which OP's don't ask but people in forum do tell about them. Do this and don't do that...

Quote:

---

Originally Posted by Paul McKenzie

The original code from the OP did have a cast, so you should direct your comment to him/her.

---

I should have pointed to both.

Quote:

---

Originally Posted by Paul McKenzie

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.

---

Sir, OP talked about using "C" on Unix Solaris.

Quote:

---

Originally Posted by exterminator

Johny - the standard IO is unbuffered by default.

---

Nope.
C streams are buffered (except stderr, usually).

Quote:

---

Originally Posted by SuperKoko

Nope.
C streams are buffered (except stderr, usually).

---

Quote:

---

Originally Posted by C working paper

the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device.

---

That implies that console output via stdout is line buffered at most (e.g. it autoflushes when a '\n' is output). I don't have the C89 standard to check against.

Quote:

---

Originally Posted by TomWidmer

That implies that console output via stdout is line buffered at most (e.g. it autoflushes when a '\n' is output). I don't have the C89 standard to check against.

---

In practice, because of the as-is rule, implementations tend to have a fully buffered stdout flushed when input is requested from the user (or perhaps after a delay, such as the v-sync).
Whether the as-is is respected by these implementations, or not, doesn't even matter since I have the experience that printf is unreliable for outputing debug info in a program that crashes.

And C streams are usually buffered for file I/O (even when these files are accessed through stdin/stdout).

Quote:

---

Originally Posted by ScorpionChief

I guess pointing such things are very common in forums. There are lot of things which OP's don't ask but people in forum do tell about them. Do this and don't do that...

---

I copied what the OP tried, and wrote a small program given what he gave us. Casting or not casting makes absolutely no difference in the program's behavior.

Besides, as exterminator pointed out, I also feel it is better to be explicit about the conversion, since this is a source of many bugs in 'C' which can be prevented with explicit casting.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

I copied what the OP tried, and wrote a small program given what he gave us. Casting or not casting makes absolutely no difference in the program's behavior.

---

Ok, fine. It might not be a problem in your code but there can be a problem in case stdlib.h, the header which declares malloc, is not included. If the return of malloc is cast then the error which would be flagged is hidden, resulting in a difficult to find bug.
Also, during maintenance, if the type of the pointer changes but the cast is not changed, once again there is a difficult to find bug.
So, I prefer not to cast.

I guess we both know what's right here and we can stop this discussion here.

Quote:

---

Originally Posted by SuperKoko

In practice, because of the as-is rule, implementations tend to have a fully buffered stdout flushed when input is requested from the user (or perhaps after a delay, such as the v-sync).
Whether the as-is is respected by these implementations, or not, doesn't even matter since I have the experience that printf is unreliable for outputing debug info in a program that crashes.

And C streams are usually buffered for file I/O (even when these files are accessed through stdin/stdout).

---

That's presumably a violation of the as-if rule, since I imagine that they don't flush complete stdout lines when a volatile variable is read or written. Looking at GNU libc, I think it correctly implements line buffering, which Microsoft's CRT seems to leave stdout completely unbuffered when it is attached to a terminal (in both cases, when stdout is redirected to a file, it is buffered, as allowed by the standard).

Quote:

---

Originally Posted by TomWidmer

That's presumably a violation of the as-if rule, since I imagine that they don't flush complete stdout lines when a volatile variable is read or written. Looking at GNU libc, I think it correctly implements line buffering, which Microsoft's CRT seems to leave stdout completely unbuffered when it is attached to a terminal (in both cases, when stdout is redirected to a file, it is buffered, as allowed by the standard).

---

No, that's not a violation of the rule. What's the standard output is implementation-defined.
If the implementation says that data is only visible after the v-sync or every two seconds, it's legal.
Moreover line buffering still is buffering.

Quote:

---

Originally Posted by SuperKoko

No, that's not a violation of the rule. What's the standard output is implementation-defined.
If the implementation says that data is only visible after the v-sync or every two seconds, it's legal.
Moreover line buffering still is buffering.

---

I would take an unqualified "buffered" to mean "fully buffered" in the C standard's parlance (particularly when the conversation relates to logging, which is usually line based). YMMV.