<mdiers_>
memory leak in hpx_main is not recognized and the message "LeakSanitizer: detected memory leaks" is missing.
<heller>
so you are not getting any leaks?
<heller>
did you compile HPX with sanitizer enabled?
<heller>
how did you compile things?
<heller>
can you post the exact output pleas?
<mdiers_>
i get the leak from main, but not from hpx_main. build hpx with HPX_WITH_SANITIZERS=ON HPX_WITH_STACK_OVERFLOW_DETECTION=OFF RelWithDebInfo -O1 -g
<heller>
with gcc or clang?
<mdiers_>
build hpx with gcc and my app with clang.
<mdiers_>
heller: added comment to gist paste
<heller>
building your app with clang might cause the problem here
JClave has joined #ste||ar
<mdiers_>
heller: i just saw that there is no liblsan available. is there a static link at clang? will i install it and test it further. thanks a lot
<JClave>
Hi all, anyone managed to get HPX to work in Visual Studio 2019? It compiled fine but apps fail to run. The doc says 2015 is recommended so theres no guarantee that HPX will work in 2019?
JClave has quit [Remote host closed the connection]
<heller>
mdiers_: no, the sanitizers are always linked in dynamically
<mdiers_>
heller: there was no dynamic liblsan on the system, but it still worked partially. I need a few minutes to create the container...
<mdiers_>
heller: need longer, because under centos7 with gcc8 what is missing
daissgr has joined #ste||ar
daissgr has quit [Remote host closed the connection]
<hkaiser>
ancient technologies always work most reliably
<Yorlik>
Dinos 4ever ! :)
* Yorlik
tosses VS out of the windows and starts doing BASIC peek() and poke() assembler again.
mdiers_ has quit [Remote host closed the connection]
mdiers_ has joined #ste||ar
<zao>
Yorlik: Only way to get usable IRC is via fancypants services like irccloud :)
<zao>
(which are probably vulnerable)
JClave has joined #ste||ar
<Yorlik>
zao: Oh yes - had may fair share of netsplits over time ...
<jbjnr>
heller: I can't access that FULT paper you mentioned. Could you send me the PDF please.
<heller>
jbjnr: sure
<jbjnr>
ta
<jbjnr>
welcome back!
<jbjnr>
see you next week yes? I forgot to contact you about it
<heller>
yes, see you next week!
<heller>
me and mikael agreed upon hijacking the call on wednesday
<heller>
btw, which hotel are you staying in?
<jbjnr>
not staying in hotel. staying in airbnb cos my wife and daughter will visit stuttgart whilst I'm at HLRS
<heller>
can you tell the address such that me and mikael are nearby so we can easily sync on wednesday evening?
<jbjnr>
no idea where it is
<jbjnr>
will need to check later
<heller>
ok
hkaiser has quit [Quit: bye]
<mdiers_>
heller: updated to gcc 8.3.1 and rebuild hpx and application with gcc. no correction. same behaviour as before.
<tarzeau>
if someone has debian or ubuntu and wants to test hpx packages?
<heller>
mdiers_: which malloc do you use?
hkaiser has joined #ste||ar
<mdiers_>
heller: HPX_WITH_MALLOC=tcmalloc
<mdiers_>
heller: i'm just surprised that it works in the main, and in the hpx_main not any more
<heller>
indeed
<heller>
I am a little clueless as well :(
<heller>
can you do a ldd on libhpx(d).so and the binary of your application?
diehlpk_mobile has joined #ste||ar
<diehlpk_mobile>
jbjnr: Are you joining the octotiger meeting?
<diehlpk_mobile>
it started already
<heller>
hkaiser: I saw something very interesting recently: future<T...> instead of tuple<future<T>...> this sounds like a nice optimization
<heller>
as a return value from when_all, for example
<K-ballo>
there were proposals along that line, future<>, future<T>, future<Ts...>
<K-ballo>
I seem to recall both matt calabresse and david sankel where independently toying with those ideas
<Yorlik>
When I overload operator new for a class do I return a void* or a typed ptr? My intuition says return a typed ptr, but I see a ton of tutorials returning a void*. For me it means return(void*)outPtr kills my data. Could someone enlighten me about this?
rtohid has quit [Quit: Konversation terminated!]
<K-ballo>
void*, operator new allocates raw memory
<K-ballo>
operator new does NOT do object construction
diehlpk_work has joined #ste||ar
<Yorlik>
IC. I think I created a homemade issue then: I use a flag inside the structure (flags::allocated ...) to indicate, if a slot inside my memory block is actually used or just a spare. That is used to allow zipping over the slots/array directly very fast and just doing a check on that flag if the data has to be processed or not.
<Yorlik>
So - I wonder if i should just ban new, or simply leave it untouched
<Yorlik>
The overall idea is to do lifetime management for these PODs from a type erased pointer anyways, so usually you'd never directly create such an object
<Yorlik>
Maybe I should just throw an exception - just in case anyone ever think he can use new for these objects
<Yorlik>
I hve put explicit allocation and initialization into two functions(create and destroy) anyways
rori has quit [Ping timeout: 245 seconds]
quaz0r has quit [Ping timeout: 245 seconds]
<mdiers_>
heller: updated gist paste with dependencies
quaz0r has joined #ste||ar
JClave has quit [Remote host closed the connection]
<Yorlik>
Is there a way to generate a compile time error inside a method( I want to generate a compile time error in overloaded new/delete for a class - above problem moved to compile time)
<K-ballo>
do you want to `=delete;` them maybe?
<Yorlik>
delete might actually work, by just unsetting the allocated flag in the memory block, but I prefer to have an unambiguous API (thinking of team members trying to make sense of it)
diehlpk_mobile has quit [Read error: Connection reset by peer]
<K-ballo>
I can't, I can't make sense of it
<Yorlik>
So - my current thought is to use the managing pointer only for everything
<Yorlik>
The objects have a static allocator and store themselves there
<Yorlik>
It is organized like an array with a freelist
<Yorlik>
There is a double purpose
<Yorlik>
It shall also be possible to zip over the array and ignore deleted slots
<Yorlik>
Thats what the flag is for
<Yorlik>
There might be holes when objects get deleted
<K-ballo>
is somehow ok to have `X x;` but not `X *p = new X();`? is that it?
<Yorlik>
X x would try to use the stack usually, right? The problem is, if i want to use my allocator for everything, i need to force handling of the "allocated" flag in any case
<Yorlik>
There is no giving back of memory
<Yorlik>
Just invalidation and later reuse
<Yorlik>
but the holes cannot be ignore, because of the array semantics being used
<K-ballo>
at function scope it would "use the stack", sure
<Yorlik>
I wonder how I could override that too with my allocator
<Yorlik>
Still learning a ton.
<Yorlik>
All in all the allocator works nicely, at least at a basic level (allocate, deallocate)
<K-ballo>
you simply can't
<K-ballo>
do you happen to need to control *all* construction?
<Yorlik>
But I want the API of the entire system to be as easy and error free to use as possible.
<Yorlik>
Just one bit
<Yorlik>
Since the entities are statically polymorph the flags are in the base
<K-ballo>
just one beet of the construction? which bit?
<K-ballo>
*bit
<Yorlik>
More or less Yes. At least for the allocation.
<Yorlik>
I use "initialized" to as a flag
<Yorlik>
"Allocated" is just a merker for the status of that slot
<Yorlik>
So - during update certain flags might just prohibit any attempt of an update operation
<K-ballo>
allocation is not up to you to control
<K-ballo>
at most you may control construction, so that it all happens via factory functions that do whatever allocation you prefer
<Yorlik>
What do you mean with "allocation is not up to you to control" ? After all I am using a custom allocator which has control over a certain memory region. I don't understand what you mean.
<K-ballo>
X x; performs allocation and construction of which you have no control over
<K-ballo>
you can't have direct control over all allocations, but you can control all constructions such that they may only be performed on storage allocated by you and your allocator
<Yorlik>
That makes sense to me.
<Yorlik>
Actually it doesn't do harm if people use T var;
<Yorlik>
For whatever special purpose
<Yorlik>
I think I'll just set new and delete to = delete and write comments
simbergm has quit [*.net *.split]
jaafar_ has quit [Remote host closed the connection]
jaafar has joined #ste||ar
Vir has quit [Ping timeout: 246 seconds]
Vir has joined #ste||ar
Coldblackice has joined #ste||ar
hkaiser has quit [Quit: bye]
Vir has quit [Ping timeout: 246 seconds]
Vir has joined #ste||ar
<heller>
K-ballo: I'm starting to like that idea as well. Not only makes it for nicer interfaces, but also allows for nice optimizations
<K-ballo>
heller: which kinds of optimizations do you have in mind?
<K-ballo>
I like the design, and I would give it thorough consideration if we were rewriting futures from scratch
<heller>
One optimization I can think of is for forking operations. Say you want to spawn N tasks, instead of needing to allocate N shared states, you can get away with one
<heller>
So maybe even extending it to vector/list/range like constructs
<heller>
Similar to our unwrapping
* K-ballo
shivers
<heller>
Reverse unwrapping, so to say
<heller>
I think this is very valuable in range algorithms
<K-ballo>
I don't want to have anything to do with our unwrapping ever again, not even in reverse
<Yorlik>
There is a second way by moving the asserts into the constructor - only for that purpose - but gcc doesn't like it
<Yorlik>
And I don't want no stinkin constructor
<Yorlik>
The practical solution is already there by just documenting the code and not doing these checks
<Yorlik>
But it's a class of problems I think, how to preotect code from being used / altered the wrong way.
<Yorlik>
So - this is not a burning problem, but IMO still an interesting and probably useful one.
<diehlpk_work>
hkaiser, see pm
<hkaiser>
Yorlik: no idea, ask K-ballo ;-)
<Yorlik>
OK. Maybe it's just not possible to solve this elegantly.
<Yorlik>
Thanks for looking into it :)
<K-ballo>
I couldn't make sense of it
<Yorlik>
Hmm
<Yorlik>
K-Ballo: The template logic is meant to create a compile time error if someone tries to undo the deletion of new or delete
<Yorlik>
Mean if delete or new resolve to a type the true specialization of the checking template is called and raises the assert
<Yorlik>
otherwise SFINAE
<Yorlik>
resp. false
<Yorlik>
But whatever - practically I dcided against the template logic and just deleted the operators and put a fat depürecation and comment in the code
<Yorlik>
So someone will have to want to intentionally break it.
<Yorlik>
I just liked the idea of additional safety / shackles ;)