I ask this here because i'm having strange behaviour (it's not the first time) i write something.
Is it normal that a program crashes if run from the shell and works fine if run from wanderer?
Thx!

First difference is that in both methods stack assigned to the program is different. When running from Wanderer stack is set on icon, when running from shell, stack is taken from environment configuration.

thx! i'll start from this!

Quote:

I've checked if there's a difference in stack availability when starting from icon or from CLI (on a recent nightly build). In both cases it is 40960 bytes. In Icaros the stack available is 1024000 bytes.

Weird thing, I've tried changing the default stack either using the STACK command in the ToolTypes tab of my application's icon or from CLI, but in both cases it seems it has no effect; what am I doing wrong?

The check is done executing FindTask() as specified here:
http://en.wikibooks.org/wiki/Aros/Dev ... r/Docs/Examples/StackSwap

The avail flush command crashes the nightly build.

thanks

I'm not sure if STACK tooltype is handled. Using Info on icon, on first tab you will have separate field for stack.

Try running your application and then invoke tasklist from shell. This command also shows stack allocated to each process/task.

If I do the following:

Create shell

> Stack 512000
> TaskList

Than in output I see TaskList process with 512000 stack.

If you want a consistent stack size in shell and wanderer, without messing with the stack command or the icon, you can use my header. Just define a global variable named __stack (a'la LibNIX), and include the header. If the stack size is smaller then the one you defined it'll allocate memory for it. A couple of shell commands which need large stack do this.

Attach file:

---

incstack.h Size: 1.30 KB; Hits: 33

@deadwood: you're right, the right way to set the stack size is from that specific field in the icon. Too obvious to even notice that

Also, I've noticed that stack size increments are automatically rounded in steps of four bytes (e.g. 40960, 40964, 40968, ...); I feel that it makes sense, but I don't quite understand why. Is it because if I could allocate 40961 instead of 40960 the remaining 3 bytes would be useless?

Thanks for clarifying this.

@BSzili: thanks, that'll come in handy. I've also stumbled upon your posts in the other thread about temporary stack allocation, your suggestions helped me too!