<hkaiser>
weilewei: there is no valid pointer at 0x48
<hkaiser>
something went horribly wrong for you
<hkaiser>
this looks like if some code used a this-pointer that was equal to zero
Yorlik has quit [Ping timeout: 240 seconds]
hkaiser has quit [Quit: bye]
<weilewei>
ok, then maybe some code logic is wrong...
<weilewei>
I think I might need the third thread data...
nikunj97 has joined #ste||ar
nikunj has joined #ste||ar
Nikunj__ has joined #ste||ar
nikunj97 has quit [Ping timeout: 244 seconds]
nikunj has quit [Ping timeout: 244 seconds]
nikunj has joined #ste||ar
bita_ has quit [Ping timeout: 264 seconds]
kale[m] has quit [Ping timeout: 264 seconds]
kale[m] has joined #ste||ar
klaus[m]1 has joined #ste||ar
Nikunj__ has quit [Quit: Leaving]
nikunj has quit [Read error: Connection reset by peer]
Yorlik has joined #ste||ar
mcopik has joined #ste||ar
mcopik has quit [Client Quit]
kale[m] has quit [Ping timeout: 264 seconds]
kale[m] has joined #ste||ar
nikunj has joined #ste||ar
kale[m] has quit [Ping timeout: 264 seconds]
kale[m] has joined #ste||ar
kale[m] has quit [Ping timeout: 256 seconds]
kale[m] has joined #ste||ar
kale[m] has quit [Ping timeout: 246 seconds]
kale[m] has joined #ste||ar
nikunj has quit [Ping timeout: 244 seconds]
nikunj has joined #ste||ar
kale[m] has quit [Ping timeout: 240 seconds]
kale[m] has joined #ste||ar
kale[m] has quit [Ping timeout: 258 seconds]
kale[m] has joined #ste||ar
nikunj97 has joined #ste||ar
hkaiser has joined #ste||ar
<Yorlik>
hkaiser: YT?
<hkaiser>
Yorlik: here
<Yorlik>
Despite using mimalloc, I realized a lot of uses of malloc and free by HPX from ucrtbase.dll in the profiler. Do you think it will use mi_malloc and - free under the hood or should the correct module (mimalloc.dll) be displayed?
Nikunj__ has joined #ste||ar
nikunj97 has quit [Ping timeout: 240 seconds]
<Yorlik>
hkaiser: ^^
<hkaiser>
the correct module should be displayed, I think
<Yorlik>
Then mimalloc is not or only partially used.
<Yorlik>
I can give my own objects according allocators or custom new/delete overrides, but I can't do anything for the HPX side as long as that special mimalloc header is broken. Should I make an issue for it?
<Yorlik>
Though I'm not sure global overriding of new/delete is always a good idea
<hkaiser>
Yorlik: I wouldn't know how to fix it
<Yorlik>
OK. I think you remarked at one point, you're using the custom allocators only by hand anyways, right?
<Yorlik>
I'm asking, because I believe some HPX objects might profit from a macro conditional override of new/delete
<Yorlik>
I'll experiment with it / hack HPX and measure.
<hkaiser>
Yorlik: on windows, yes
rajpalsanyam1997 has joined #ste||ar
<rajpalsanyam1997>
Hey everyone, I am a first-time contributor and I am interested in this Stellar. I want to make some open source contributions and learn.
<rajpalsanyam1997>
Sanyam
<Nikunj__>
rajpalsanyam1997, welcome aboard!
Nikunj__ is now known as nikunj97
<nikunj97>
hkaiser, I've started working on the blog :D
<nikunj97>
hkaiser, this week I'll write about most of the functionalities. Then I'll send a link on hpx-dev mailing list for you guys to review it before posting.
<nikunj97>
jbjnr, you will be interested in it as well ^^
<hkaiser>
nikunj97: perfect!
<hkaiser>
thanks
<hkaiser>
rajpalsanyam1997: hey Sanyam, welcome
<nikunj97>
hkaiser, btw I did add a PR for the scalable 1d stencil
<hkaiser>
nikunj97: yah, saw that - have not had a look, though - sorry
<hkaiser>
gtg
hkaiser has quit [Quit: bye]
nikunj has quit [Read error: Connection reset by peer]
nikunj has joined #ste||ar
nikunj has quit [Ping timeout: 260 seconds]
nikunj97 has quit [Read error: Connection reset by peer]
nikunj has joined #ste||ar
nikunj97 has joined #ste||ar
Nikunj__ has joined #ste||ar
otto[m] has joined #ste||ar
nikunj97 has quit [Ping timeout: 260 seconds]
Nikunj__ has quit [Remote host closed the connection]
Nikunj__ has joined #ste||ar
nikunj97 has joined #ste||ar
Nikunj__ has quit [Ping timeout: 260 seconds]
<weilewei>
ok, after adding a vector of size_t in hpx thread data, libcds stress tests passed mostly. flat_combining tests are the last one failing, possibly due to using kernel-level locks.
<weilewei>
one thing I realized is that for c++11, if same thread_local variables are used but they are in different namespace, they are still different variables...
nikunj97 has quit [Read error: Connection reset by peer]
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
kale[m] has quit [Ping timeout: 240 seconds]
kale[m] has joined #ste||ar
weilewei has quit [Ping timeout: 245 seconds]
nikunj97 has joined #ste||ar
nikunj97 has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
kale[m] has quit [Ping timeout: 260 seconds]
<ms[m]>
weilewei: what do you mean by the last bit? If they're in different namespaces they're not the same variables?