14:41 <jbjnr_> NB. The jemalloc munmap errors have been common recently. I see them when I'm running and the linear algebra people have seen them too on daint (using their own build of hpx). (I have my own theory about it).

15:24 <heller> which is?

15:25 <jbjnr_> hkaiser: is there any easy call like find_here() that returns rank 0 locality I'm looking for find_agas() or something, but can't seem to locate one

15:26 <jbjnr_> heller: stack misuse

15:27 <jbjnr_> I had much better behaviour on the lazy stack init branch. I wish there were more hours in the day to fix all this stuff.

15:27 <jbjnr_> I think hpx::loc:barrier might be buggy.

15:28 <jbjnr_> hpx::lcos::barrier I mean. It may be causing my lockups

15:28 <heller> ok

15:30 <heller> so you are saying that there are too many stacks allocated?

15:30 <heller> while that might be true

15:31 <hkaiser> jbjnr_: sure

15:31 <heller> it still is a hint that the application just creates too many threads

15:31 <hkaiser> sec

15:31 <jbjnr_> heller: absolutely correct

15:31 <jbjnr_> combine that with bad reuse of memory ...

15:32 <heller> *nod*

15:32 <heller> fixing this will still mean that the application has a performance problem, no?

15:32 <jbjnr_> (I've been working on that in my scheduler cleanup, but it's not finished)

15:33 <jbjnr_> ^^not sure.

15:33 <hkaiser> jbjnr_: hpx::agas::get_console_locality()

15:34 <jbjnr_> heller: we just shouldn't allow executors to keep creating tasks without limit ... (limiting executor)

15:34 <jbjnr_> hkaiser: thanks. perfect

15:34 <jbjnr_> I searched for all regexes apart form that one

15:34 <heller> jbjnr_: if the application is written that way ... we can't bound the creation of tasks in general, that will mean trouble for our forward progress guarantee

15:35 <jbjnr_> not necessarily. as long as locks aren't held....

15:36 <jbjnr_> progress is still made, just not on the spawning thread

15:45 <heller> right, which might be a problem

15:45 <heller> even without locks

15:47 <jbjnr_> the spawning thread will be resumed - that is guaranteed, so nothing changes. Ig any other thread suspends, then the spawning thread can resume. The only case where it doesn't is if all tasks run indefinitely or take OS locks - in that case, there is a problem anyway.

15:48 <jbjnr_> s/ig/if/

15:48 <jbjnr_> hkaiser: is it possible that barrier has bugs?

15:48 <jbjnr_> how well tested is it?

15:48 <jbjnr_> could the order that ranks enter the barrier trigger a corner case?

15:53 <hkaiser> jbjnr_: anything is possible

15:54 <hkaiser> jbjnr_: local::barrier or the distributed one?

15:54 <jbjnr_> distributed

15:54 <hkaiser> ask heller ;-)

15:54 <jbjnr_> I thought you rewote it. sorry.

15:54 <hkaiser> we use it heavily during startup, so it uses at least for those use cases

15:54 <hkaiser> no heller rewrote it

15:55 <jbjnr_> Seems like I have a case where if rank 0 is last to enter the barrier, I get a deadlock. Not certain about it, but it looks suspicious

15:55 <hkaiser> s/uses/works/

15:55 <hkaiser> jbjnr_: could be

18:05 <diehlpk_work> jbjnr_, Will you attend the meeting today?

18:36 <aserio> jbjnr_: Will you be joining the Operation Bell Meeting today?

20:16 <diehlpk_work> jbjnr_, yet?

21:29 <hkaiser> parsa: yt?

21:29 <hkaiser> parsa: any idea what happened here: https://circleci.com/gh/STEllAR-GROUP/phylanx/22748 ?

21:29 <hkaiser> (many others are failing similarily)

21:51 <parsa> hkaiser: looking right now

21:54 <hkaiser> parsa: thanks!

21:57 <parsa> hkaiser: there is an extra <CR> at the beginning of the conv.xsl. no clue where it came from. it doesn't exist in the live url and we don't manipulate the file anywhere

22:29 <hkaiser> parsa: let's rerun and see what happens