aserio changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
<K-ballo>
I missed that there's more than just the the one instance of the issue
<K-ballo>
I'll run some more test tomorrow
<zao>
I should run a -k and see if there's some other test that also manifests it.
<github>
hpx/fix_2931 d5f048f Hartmut Kaiser: Returning parse-result from resource_partitioner initialization
<hkaiser>
heller: pls verify I haven't make a mess of #2931
<heller>
hkaiser: perfect
<heller>
hkaiser: hpx::lcos::base_lco_with_value<hpx::util::unused_type, hpx::util::unused_type> should never be instantiated, no? shouldn't it rather be: hpx::lcos::base_lco_with_value<void, hpx::util::unused_type>?
<hkaiser>
don't ask - compiler problem
<hkaiser>
but yah - should be instantiated, ever
<hkaiser>
without this instantiation I see linker errors, though
<hkaiser>
should not*
<heller>
very strange
<hkaiser>
indeed - but we have that in there for quite some time
<heller>
yeah
<heller>
I was just wondering if that could not be related to those wrapper heap problems we see on master
<heller>
but doesn't seem to be the case
<hkaiser>
hmmm
<hkaiser>
the wrapper heap problems are somehow caused by your recent changes
<heller>
yeah, I know
<heller>
well, similar problems did exist before, after your changes ;)
<heller>
my changes were an attempt to fix those
<hkaiser>
k
<heller>
which didn't seem to be very effective
<heller>
i can't reproduce this problem with any other code than those few failing tests
<hkaiser>
interesting - but you do can reproduce them?
<hkaiser>
K-ballo: have you updated to VS15.5 yet?
<K-ballo>
hkaiser: yep
<hkaiser>
lot'sa problem for me
<hkaiser>
do you have any problems?
<K-ballo>
not with HPX
<K-ballo>
other than all those warnings
<hkaiser>
I'm seeing bodus compiler problems around template pack expansion, even an ICE
<hkaiser>
bogus
<K-ballo>
how to reproduce?
parsa has quit [Quit: Zzzzzzzzzzzz]
<hkaiser>
the ICE you can reproduce by compiling the foreach_prefetch_... tests
<hkaiser>
the template pack problems by compiling the phylanx core module
<heller>
hkaiser: I can reproduce them with the tests, yes
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
parsa has joined #ste||ar
EverYoung has quit [Ping timeout: 255 seconds]
<heller>
hkaiser: oh oh. it looks like we are dealing with a double free error here
<K-ballo>
since the update msvc keeps running out of memory
hkaiser_ has joined #ste||ar
<hkaiser_>
K-ballo: I solved the issue by switching to <variant> for the new compiler :/
<K-ballo>
oh, so it was an mpark/variant issue?
<K-ballo>
I remember reading some issue reports, my variant got a similar one too
hkaiser has quit [Ping timeout: 268 seconds]
<K-ballo>
keep in mind <variant> doesn't work with /std:c++14
<hkaiser_>
nod, I know
<hkaiser_>
idiotic anyways
diehlpk has quit [Ping timeout: 255 seconds]
<jbjnr>
just fyi - pycicle stopped on greina due to github timeout that my trc/except block didn't catch. restarted it and pr's building again
<hkaiser_>
jbjnr: nice, thanks
<hkaiser_>
jbjnr: is there a way to tell github that the tests are running, currently it reports the results after its done only
Smasher has quit [Remote host closed the connection]
Smasher has joined #ste||ar
<jbjnr>
hkaiser_: yes, I just haven't got around to adding that. wanted to get it stable and reliable before adding some of the bells and whistled
<hkaiser_>
no pressure, just asking - tks
<jbjnr>
handling ultiple compilers and build options requires quite a lot of changes and I don't want to spam githum with 'erroneous' reports etc
<heller>
jbjnr: yeah, we need one status for each config ;)
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
ct-clmsn has joined #ste||ar
ct-clmsn is now known as Guest70026
Guest70026 has quit [Client Quit]
ct-clmsn_ has joined #ste||ar
mcopik has quit [Ping timeout: 268 seconds]
<heller>
hkaiser_: ok, not a double free per see. The wrapper heap itself got cleaned up too early. might have been me after all
<heller>
yup. it was me
<heller>
CXX1z is what the unreleased 17 was called before, right?
<K-ballo>
yep
Smasher has quit [Remote host closed the connection]
<heller>
hkaiser_: it's essentially bringing back this change, I forgot the free_size_ check when I fixed the alignment problem
<hkaiser_>
ahh, ok
<hkaiser_>
just looks strange
<hkaiser_>
freesize < capacity doesn't sound right - but I'm not sure
<heller>
the whole wrapper_heap looks strange, if you ask me
<hkaiser_>
heller: that's unrelated ;)
<heller>
the logic is: it can only hold capacity elements. only if all elements got deleted, that is, when free_size_ equals capacity again, we should release this wrapper heap
<heller>
it is
<hkaiser_>
k
<heller>
jbjnr: is there any way I can retrigger a build with pycicle right now?
<heller>
hkaiser_: so the "pointer 0x255de98 was not allocated by this one_size_heap_list" was not caused by duplicate symbols, but by the fact, that the corresponding heap list was released too soon
<heller>
really strange that it didn't come up with other applications
<hkaiser_>
requires a certain amount of allocs/frees
<K-ballo>
zao: I'll open a PR
<zao>
K-ballo: Other code still fails to compile, of course.
<github>
hpx/master ffa2600 Thomas Heller: Adding missing includes
<zao>
:D
<heller>
hkaiser_: regarding #3063, did you see an improvement in the codegen?
mcopik has joined #ste||ar
diehlpk has joined #ste||ar
<hkaiser_>
heller: not for msvc, I was hoping to see some for gcc et.al.
<hkaiser_>
K-ballo: what's the problem with bind_back (#3065)
<K-ballo>
hkaiser_: it's not with bind_back, it's with .. everything else, don't yet know exactly what
<hkaiser_>
heh
<K-ballo>
instantiations in unevaluated contexts during overload resolution, poison
<K-ballo>
happens for timed executors with exactly one argument
<hkaiser_>
strange
<K-ballo>
not so, the trace for dispatching to executors is anything but simple
<hkaiser_>
it is, I'm not even sure if I got everything right
<K-ballo>
something in it is touching an overload that won't actually be used, but that causes an attempt to copy a movable only thing in an unevaluated context
<hkaiser_>
some forward missing, somewhere
<K-ballo>
maybe
<K-ballo>
but not in the functions that are actually called
<K-ballo>
in some overload that gets instantiated but not picked
<K-ballo>
not really instantiated, but substituted
<hkaiser_>
cleaning those dispatch chains up is still on my list - can't get myself to do it :/
<hkaiser_>
especially with the recent executor changes...
parsa has quit [Quit: Zzzzzzzzzzzz]
ct-clmsn_ has quit [Ping timeout: 240 seconds]
gedaj has joined #ste||ar
parsa has joined #ste||ar
<jbjnr>
heller: retrigger - sorry, not yet implemented, but will add "pycicle build" check to comments on PRs
<jbjnr>
just got first clang builds running on daint. will add retrigger tomorrow if you like
<jbjnr>
tell me which PR needs it and I'll set it going - bunch just started on daint, so it's probably going now