K-ballo 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/
bita has quit [Ping timeout: 260 seconds]
hkaiser has joined #ste||ar
hkaiser has quit [Quit: bye]
bita has joined #ste||ar
bita has quit [Ping timeout: 264 seconds]
klaus[m] has quit [Quit: Bridge terminating on SIGTERM]
gnikunj[m] has quit [Quit: Bridge terminating on SIGTERM]
parsa[m] has quit [Quit: Bridge terminating on SIGTERM]
rori has quit [Quit: Bridge terminating on SIGTERM]
tiagofg[m] has quit [Quit: Bridge terminating on SIGTERM]
teonnik has quit [Quit: Bridge terminating on SIGTERM]
k-ballo[m] has quit [Quit: Bridge terminating on SIGTERM]
gonidelis[m] has quit [Quit: Bridge terminating on SIGTERM]
mdiers[m] has quit [Quit: Bridge terminating on SIGTERM]
ms[m] has quit [Quit: Bridge terminating on SIGTERM]
pedro_barbosa[m] has quit [Quit: Bridge terminating on SIGTERM]
jpinto[m] has quit [Quit: Bridge terminating on SIGTERM]
tiagofg[m] has joined #ste||ar
gonidelis[m] has joined #ste||ar
klaus[m] has joined #ste||ar
rori has joined #ste||ar
gnikunj[m] has joined #ste||ar
mdiers[m] has joined #ste||ar
pedro_barbosa[m] has joined #ste||ar
ms[m] has joined #ste||ar
heller1 has joined #ste||ar
jpinto[m] has joined #ste||ar
teonnik has joined #ste||ar
parsa[m] has joined #ste||ar
k-ballo[m] has joined #ste||ar
hkaiser has joined #ste||ar
<ms[m]>
hkaiser: any objections to making the first rc this week (say tomorrow)?
<hkaiser>
not at all
<hkaiser>
I have only the actions PR in the pipeline left and plan to look into the remaining issues
<hkaiser>
ms[m]: we might consider pulling in the hwloc test, but I don't know how to verify it
<hkaiser>
zao: do you happen to have a BSD system you could try that on?
<ms[m]>
yes, the hwloc one would be nice to have
<zao>
I have no remaining physical BSD machines, but depending on what it needs a VM might do. Only thing that's kind of off-limits there is SMT.
<hkaiser>
zao: see #5121
<hkaiser>
ms[m]: could go in after the rc though
<ms[m]>
yeah, anything that is still marked 1.6.0 (or other fixes that might come in) can still go in the release, I just thought we should get the rc out to users sooner rather than later
<hkaiser>
nod, thanks!
<zao>
hkaiser: Somewhat slammed with work recently, gonna see if there's something I can rig up.
<mdiers[m]>
hkaiser: I just added another callstack. I still have it in the debugger. Are there still certain variables needed?
<hkaiser>
zao: sure, no rush - thanks
<hkaiser>
mdiers[m]: callstack of the initial issue?
<hkaiser>
or the one related to locking?
<mdiers[m]>
If it is, yes. But only with O2 optimization. I do not get segfault with O1/O0.
<hkaiser>
mdiers[m]: I meant: which of the callstacks are you talking about, the ticket has at least three different ones
<mdiers[m]>
They all look quite similar: future_data_base<void>::set_value -> condition_variable::notify_one
<hkaiser>
mdiers[m]: could you collect the backtraces for all threads, that might give us some more information
<mdiers[m]>
hkaiser: That's a big pile 😀
<hkaiser>
mdiers[m]: I know, many might look identical, however - I'm looking for some hints what other thread smight be up to the very same moment
<mdiers[m]>
hkaiser: Yes, I will collect it and also still look through it to see if I will see something there, or if I will find something recurring there.
<hkaiser>
mdiers[m]: thank you a lot!
<mdiers[m]>
hkaiser: I just tried to enable a simple screensharing under linux, but gave up.
weilewei has joined #ste||ar
weilewei has quit [Quit: Connection closed]
<zao>
This is going to be a long journey...
<zao>
[ 0%] Building CXX object libs/core/debugging/CMakeFiles/hpx_debugging.dir/src/print.cpp.o
<zao>
/say /home/zao/stellar/hpx/libs/core/debugging/src/print.cpp:264:17: error: use of undeclared identifier 'gethostname'
<zao>
Not this again... have we not learned anything since last time? :D "error: use of undeclared identifier 'environ'"
<zao>
This codebase brings back so many memories: "#error No default_context_impl available for this system"
<zao>
environ gets the // treatment, generic context stuff from CMake files that used to be there is gone for all but Apple, re-adding.
heller1 has quit [Quit: Idle for 30+ days]
<zao>
None of this looks like it used to, and I don't see most of my painstakingly made fixes.
<zao>
I shouldn't have put on the stellar-group T-shirt this morning :D
shahrzad has joined #ste||ar
<hkaiser>
zao: uhh
<hkaiser>
zao: I don't think we have removed any of the frebsd/bsd workarounds, at least not conciously
<hkaiser>
for the coroutines stuff, you always had to explicitly specify that to cmake on bsd
<hkaiser>
iirc
<zao>
I guess that some of the work I did last time was never merged.
<zao>
So yeah, about the environ stuff, the tree has gotten weird since I last touched HPX, with /full/ directories and things that I don't know how they fit together anymore.
<zao>
A refresher: FreeBSD doesn't provide `extern char** environ;` for dynamic libraries, it's part of the crt entrypoint of applications.
<zao>
Breaks on gethostname (just include unistd.h) and environ (harder).
<hkaiser>
looks like something new
<zao>
There's also an usage in libs/full/program_options/src/parsers.cpp
<hkaiser>
ok
<hkaiser>
zao: I'll fix it, give me some time
<zao>
Might be more elsewhere too, this is how far I got before the linker failures started coming in.
<hkaiser>
ok - sorry for wasting your time
<zao>
I'll keep this OS installation around, it's on a disk in physical hardware so I just have to reboot the machine from whatever other OS I happen to be running.
<hkaiser>
ok, I'll get back to you
<zao>
It quad-boots Windows, Ubuntu, macOS and now FreeBSD - and has a VR headset and a steering wheel attached :D
<hkaiser>
nice
bita has joined #ste||ar
<zao>
Looking into whether we can use <libprocstat.h> to just read the environment out of our own process.
<zao>
hkaiser: Since FreeBSD 9 there's a libprocstat library that can be used to pull out information about the running process, but requires linking to a dynamic library. Is it OK to have such a dependency on a platform, and can it be expressed in HPX's build/pkg-config/cmake? See https://gist.github.com/zao/4c877240f9ebf59633b715363bfb01c1 for demo
<hkaiser>
zao: ok, I wouldn't want to make that change now, I was planning to fix the environ issue first
<zao>
Right, just digging for alternatives.
<hkaiser>
zao: so form what I saw, the changes we made previously are all still in place. We did add new spots, though where we forgot about bsd
<zao>
Other tests in CMake uses « ${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD" »
<hkaiser>
ok
<zao>
Ignoring that, "examples/quickstart/init_globally.cpp" is missing logic for producing __argc and __argv
<hkaiser>
I can try that - didn't find anything describing how to identify FreeBSD
<hkaiser>
example: fair!
<zao>
I have yet to build "tests" or "examples", this is just `cmake --build`.
<hkaiser>
ok, cool - getting there
<hkaiser>
zao: how can I access argc/argv on freebsd? same logic?
<zao>
I don't remember.
<hkaiser>
I'll look around how we solved it in other places
<hkaiser>
or just disable the example on freebsd ;-)
<hkaiser>
zao: for the example, would simply using the Linux logic for freebsd as well work? i.e. using the gcc __attribute__((section(".preinit_array"))) ?
<zao>
No, that seems to be a glibc-specific trick.
<hkaiser>
ok
<hkaiser>
too bad ;-)
<hkaiser>
zao: I have disabled the example for now
<zao>
Hrm, might actually work on specific architectures, the issue I'm reading is a bit sprawling.
<zao>
examples target builds, 500-some into tests.
<zao>
can probably pull down the hwloc PR here then, whatever it does :)
<hkaiser>
so your system spports reporting cores, the ticket mentions that on some systems cores are not being reported
<zao>
I seem to have the rather stable hwloc 1.11, while the reporter talks about hwloc2.
<hkaiser>
could be, yah
<hkaiser>
thanks for helping anyways, this is great!
<zao>
I can probably sort out a version of hwloc2 later, either from ports or source.
<zao>
make -k0 finished, the only test failing to build is the one mentioned above with -lmemory_component, the pkg-config ones (as I have not installed HPX), and the ones with Makefiles, as those are not BSD make compliant.
<zao>
Is there any suitable test to provoke the hwloc failures, or should pretty much any of them do it?