hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
hkaiser has quit [Quit: Bye!]
sarkar_t[m] has quit [*.net *.split]
srinivasyadav227 has quit [*.net *.split]
RostamLog has joined #ste||ar
srinivasyadav227 has joined #ste||ar
sarkar_t[m] has joined #ste||ar
pansysk75[m] has joined #ste||ar
sarkar_t[m] has quit [Ping timeout: 272 seconds]
sarkar_t[m] has joined #ste||ar
Yorlik has joined #ste||ar
K-ballo has quit [Ping timeout: 248 seconds]
K-ballo1 has joined #ste||ar
K-ballo1 is now known as K-ballo
hkaiser has joined #ste||ar
<Yorlik>
hkaiser: yt ?
<hkaiser>
Yorlik: barely, still no coffee ;-)
<Yorlik>
I finally got HPX serialization for us working, but we have some UB wrinkles, probably due to lifetime issues, I still need to iron out. serialize_buffer caused errors, so I had to fall back to gsl::span for the backing buffer when deserializing incoming messages.
<hkaiser>
ok
<Yorlik>
I'm already at my second batch coffee ... :)
<hkaiser>
if serialize_buffer has issues, I'd like to know - can you reproduce this?
<Yorlik>
Probably yes - but I need to fix this UB stuff before. It's enerving.
<hkaiser>
what 'UB stuff'?
<Yorlik>
Under not yet clear circumstance we get message corruption and I don't know where it is happening.
<Yorlik>
I'll probably make a soak app with client and server in itself.
<Yorlik>
That will helkp debugging this.
<hkaiser>
ok
<hkaiser>
just let me know if I can help in any ways
<Yorlik>
If there is anything HPX related I'll not hesitate to ask. Anything else would quickly become exploitation of your time, so try to filter this stuff a lot.
<zao>
I'll offer the good old gamedev advice: "have you considered not doing things wrong? ;)"
<hkaiser>
lol - good one
<Yorlik>
:P
<Yorlik>
hkaiser: Found the issue, but I'm not sure my solution is OK.
<Yorlik>
A local variable was going out of scop and that caused the corruption, however - making it static preserved it.
<hkaiser>
Yorlik: so you _have_ considered not doing things wrong after all - good ;-)
<Yorlik>
It's inside a critical region anyways.
<Yorlik>
So the array (it's a std::array) of queues persists.
<Yorlik>
Gotta do more testing now, but that was interesting.
<hkaiser>
doesn't sound like a good solution - it's not thread-safe....
<Yorlik>
I'll surely have to rework it. But the static var is inside the critical region where the data is accessed. Still - not optimal.
<hkaiser>
if it was accessed only inside the region it wouldn't be problematic to let it go out of scope at the end
<Yorlik>
I guess it's still UB: Most likely there's some async code at a lower level - at least I now know where it's happening (sortof). Gotta dig deeper.
<Yorlik>
I was increasing the send frequency drastically - so there's a race somewhere.
<Yorlik>
The static array just covers it up for slow speeds.
hkaiser has quit [Quit: Bye!]
<zao>
My favourite trick when it comes to use-after-free is to put things in a dedicated low-level allocation and make the pages non-readable and non-writeable, waiting for it to explode.