Re: testing if data is allocated on the stack or heap

2017-10-18 Thread Biotronic via Digitalmars-d-learn
It's worth pointing out, btw, that the main reason for this code is to help drug diagnose his or her problem, not to be the be-all, end-all of stack identifying functions. :) It will of course not correctly identify pointers to variables on other threads' stacks, and fiber stacks probably

Re: testing if data is allocated on the stack or heap

2017-10-18 Thread Biotronic via Digitalmars-d-learn
On Tuesday, 17 October 2017 at 23:59:19 UTC, Steven Schveighoffer wrote: On 10/17/17 7:32 PM, flamencofantasy wrote: On Tuesday, 17 October 2017 at 17:27:17 UTC, Biotronic wrote: On Tuesday, 17 October 2017 at 15:33:02 UTC, drug wrote: [...] I have very little knowledge about sbrk, so

Re: testing if data is allocated on the stack or heap

2017-10-18 Thread Jonathan M Davis via Digitalmars-d-learn
On Tuesday, October 17, 2017 18:33:02 drug via Digitalmars-d-learn wrote: > My code fails and I guess the reason is I have a slice to data in the > stack and it becomes garbage in some moment. So I need a way to check > where data is placed. Is it right that it can be done in linux using > `sbrk`

Re: testing if data is allocated on the stack or heap

2017-10-18 Thread flamencofantasy via Digitalmars-d-learn
On Tuesday, 17 October 2017 at 23:59:19 UTC, Steven Schveighoffer wrote: On 10/17/17 7:32 PM, flamencofantasy wrote: On Tuesday, 17 October 2017 at 17:27:17 UTC, Biotronic wrote: On Tuesday, 17 October 2017 at 15:33:02 UTC, drug wrote: [...] I have very little knowledge about sbrk, so

Re: testing if data is allocated on the stack or heap

2017-10-17 Thread Steven Schveighoffer via Digitalmars-d-learn
On 10/17/17 7:32 PM, flamencofantasy wrote: On Tuesday, 17 October 2017 at 17:27:17 UTC, Biotronic wrote: On Tuesday, 17 October 2017 at 15:33:02 UTC, drug wrote: [...] I have very little knowledge about sbrk, so here's my solution. Tested on win32 and win64. [...] Try this; unittest {

Re: testing if data is allocated on the stack or heap

2017-10-17 Thread flamencofantasy via Digitalmars-d-learn
On Tuesday, 17 October 2017 at 17:27:17 UTC, Biotronic wrote: On Tuesday, 17 October 2017 at 15:33:02 UTC, drug wrote: [...] I have very little knowledge about sbrk, so here's my solution. Tested on win32 and win64. [...] Try this; unittest { int[5*1024] n; int* p = new int;

Re: testing if data is allocated on the stack or heap

2017-10-17 Thread user1234 via Digitalmars-d-learn
On Tuesday, 17 October 2017 at 17:27:17 UTC, Biotronic wrote: On Tuesday, 17 October 2017 at 15:33:02 UTC, drug wrote: [...] I have very little knowledge about sbrk, so here's my solution. Tested on win32 and win64. [...] Nice solution. Is `stackStart` thread local on purpose?

Re: testing if data is allocated on the stack or heap

2017-10-17 Thread drug via Digitalmars-d-learn
17.10.2017 20:27, Biotronic пишет: module stackCheck; private size_t stackStart; enum size_t pageSize = 0x1000; static this() {     import core.stdc.stdlib : alloca;     stackStart = cast(size_t)alloca(size_t.sizeof) & ~(pageSize-1); } bool onStack(void* p) {     size_t end = (cast(size_t)

Re: testing if data is allocated on the stack or heap

2017-10-17 Thread Biotronic via Digitalmars-d-learn
On Tuesday, 17 October 2017 at 15:33:02 UTC, drug wrote: My code fails and I guess the reason is I have a slice to data in the stack and it becomes garbage in some moment. So I need a way to check where data is placed. Is it right that it can be done in linux using `sbrk` so that if the addr

testing if data is allocated on the stack or heap

2017-10-17 Thread drug via Digitalmars-d-learn
My code fails and I guess the reason is I have a slice to data in the stack and it becomes garbage in some moment. So I need a way to check where data is placed. Is it right that it can be done in linux using `sbrk` so that if the addr of data is less than `sbrk(0)` returning then data is on

Re: testing if data is allocated on the stack or heap

2017-10-17 Thread drug via Digitalmars-d-learn
https://run.dlang.io/is/vOh6YY