These are chat archives for bluescarni/piranha

14th
Nov 2016
Francesco Biscani
@bluescarni
Nov 14 2016 10:41
@isuruf Sorry didn't see the chat yesterday
Francesco Biscani
@bluescarni
Nov 14 2016 12:32
@isuruf I am cancelling appveyor builds as I need them at work at the moment (it should not interfere with your work on travis osx)
Isuru Fernando
@isuruf
Nov 14 2016 12:32
Sorry I forgot to add [skip appveyor]
Francesco Biscani
@bluescarni
Nov 14 2016 12:32
no problem :)
btw I meant to ask, is there a specific reason to go for xcode 6.1 rather than a later version?
Isuru Fernando
@isuruf
Nov 14 2016 12:33
thread_local was working fine in others
I mean the check was working fine
Francesco Biscani
@bluescarni
Nov 14 2016 12:34
you mean the check with int rather than std::vector?
Isuru Fernando
@isuruf
Nov 14 2016 12:34
yes
Francesco Biscani
@bluescarni
Nov 14 2016 12:34
ok cool... maybe it's also useful to have an earlier version of xcode for binary packaging support?
Isuru Fernando
@isuruf
Nov 14 2016 12:35
yes. conda-forge supports OS X 10.9
In the last travis run, 2,6,7,8,13,15,16 failed. I've fixed 6,7,8. Do you know why others failed?
Francesco Biscani
@bluescarni
Nov 14 2016 12:38
do you have any experience building python binary wheels on OSX? I started providing those for pyranha windows 64 bit: https://pypi.python.org/pypi/pyranha/0.7
let me check
Isuru Fernando
@isuruf
Nov 14 2016 12:39
No, I'd rather wait for the pynative PEP to go through
Francesco Biscani
@bluescarni
Nov 14 2016 12:39
oh wasn't aware of that
Isuru Fernando
@isuruf
Nov 14 2016 12:39
We do provide binaries for all through conda
Francesco Biscani
@bluescarni
Nov 14 2016 12:40
do you have any reference for pynative?
Francesco Biscani
@bluescarni
Nov 14 2016 12:41
so it seems like 2 is now running fine in the latest travis
cheers
the earlier failure of 2 looks like a compiler bug
Isuru Fernando
@isuruf
Nov 14 2016 12:41
Maybe that should go into allowed_failures as it is a compiler bug?
Francesco Biscani
@bluescarni
Nov 14 2016 12:42
it seems to work now, I would hope it's deterministic :)
but yeah, if it happens again it's a good approach
13, 15 and 16 look all like segfaults when running tests
my first thought is that there is some mismatch between the libraris against which the executables have been linked and the libraries loaded at runtime
Francesco Biscani
@bluescarni
Nov 14 2016 12:47
I think we should figure out the tutorial build failing first, as that should be simpler
Could this be because of the cast in random number generators?
Francesco Biscani
@bluescarni
Nov 14 2016 12:50
I can't see how that would happen
how did you figure out about that cast, by the way? clang warning?
Isuru Fernando
@isuruf
Nov 14 2016 12:51
yes, only from appleclang
Francesco Biscani
@bluescarni
Nov 14 2016 12:52
ok... it looks a bit weird because it seems to imply at some difference in the types of the rng between implementations, I am wondering if there's some 32 vs 64 bit going on
in any case that bit of code should work regardless of casting, that line is just to init the rng with some number, it does not really matter which
just a random seed
Isuru Fernando
@isuruf
Nov 14 2016 12:56
uint_fast32_t is 8 bytes on my Linux, but it maybe 4 on travis-ci OSX
Francesco Biscani
@bluescarni
Nov 14 2016 12:57
possibly yeah, in the end it's just a typedef to some other type. maybe it's a libc++ vs libstdc++ thing
gonna try to diff the two commits
I can't access the working commit? bluescarni/piranha@52a7b00
Isuru Fernando
@isuruf
Nov 14 2016 13:01
Ah, I rebased, see this one, bluescarni/piranha@07e8166
It worked as well
Francesco Biscani
@bluescarni
Nov 14 2016 13:15
not sure what is going on, it's puzzling that the release build works but the tutorial one does not
the only changes I see that could cause this are path-related, but I cannot pinpoint
I need to context switch for a while, I'll be back later
Isuru Fernando
@isuruf
Nov 14 2016 13:19
Okay. see you then
Francesco Biscani
@bluescarni
Nov 14 2016 13:19
I am still around but I have job-related stuff that needs urgent care :)
thanks a lot for the help on osx
Isuru Fernando
@isuruf
Nov 14 2016 13:20
Me too. got loads assignments to grade
Francesco Biscani
@bluescarni
Nov 14 2016 13:20
are you teaching as well?
Isuru Fernando
@isuruf
Nov 14 2016 13:21
TA
Francesco Biscani
@bluescarni
Nov 14 2016 13:21
nice
Isuru Fernando
@isuruf
Nov 14 2016 13:21
Actually I'm an RA, but have to do some ta things as well
Francesco Biscani
@bluescarni
Nov 14 2016 13:22
maths?
Isuru Fernando
@isuruf
Nov 14 2016 13:22
CS
Isuru Fernando
@isuruf
Nov 14 2016 14:30
I just realized that the tutorial started failing in my branch after I rebased on top of master
Francesco Biscani
@bluescarni
Nov 14 2016 15:05
mhmh
Francesco Biscani
@bluescarni
Nov 14 2016 19:43
@isuruf you there?
Isuru Fernando
@isuruf
Nov 14 2016 19:43
yes
Francesco Biscani
@bluescarni
Nov 14 2016 19:43
I was diffing the logs of the release vs tutorial build
the difference is that the tutorial build is built with clang
the release with gcc
Isuru Fernando
@isuruf
Nov 14 2016 19:44
and the python builds as well
Francesco Biscani
@bluescarni
Nov 14 2016 19:44
right... I am wondering if maybe there's an incompatibility between the boost libraries installed via conda and clang?
Isuru Fernando
@isuruf
Nov 14 2016 19:44
yes. there might be
Francesco Biscani
@bluescarni
Nov 14 2016 19:44
maybe because of C++ abi or stuff like that
Isuru Fernando
@isuruf
Nov 14 2016 19:45
But the builds in ubuntu repos work fine
Francesco Biscani
@bluescarni
Nov 14 2016 19:45
yes.. but those are builds specifically backported for that old ubuntu version
Isuru Fernando
@isuruf
Nov 14 2016 19:46
conda libraries are also built using an ancient centos docker image
Francesco Biscani
@bluescarni
Nov 14 2016 19:52
sorry baby woke up
I'll google a bit to see if something comes up
Francesco Biscani
@bluescarni
Nov 14 2016 20:06
wondering if it would be worth a try to attempt compilation against the ubuntu boost, just to see if that's the issue
Francesco Biscani
@bluescarni
Nov 14 2016 20:24
Isuru Fernando
@isuruf
Nov 14 2016 20:27
Now we know what's going on. I wonder why it worked before
Francesco Biscani
@bluescarni
Nov 14 2016 20:30
when it worked, was it using clang as well?
Isuru Fernando
@isuruf
Nov 14 2016 20:31
yes
Francesco Biscani
@bluescarni
Nov 14 2016 20:32
I really can't see anything in the PR I merged before you rebased that could have caused this problem
really weird
Francesco Biscani
@bluescarni
Nov 14 2016 20:43
I suppose I could switch over the tutorial and python builds to GCC, could actually be an excuse to have a gcc 6 used as well in the CI
the original motivation for having clang compile the python binding is that clang is faster and easier on memory, but the advantage wrt GCC has reduced recently
Isuru Fernando
@isuruf
Nov 14 2016 20:43
Or you could just use boost from apt for linux and only use boost from conda for osx
Francesco Biscani
@bluescarni
Nov 14 2016 20:44
yeah that would work as well
Isuru Fernando
@isuruf
Nov 14 2016 20:53
That wouldn't work for the python builds
Francesco Biscani
@bluescarni
Nov 14 2016 20:54
because the boost python library would be incompatible with the conda-provided python?
Isuru Fernando
@isuruf
Nov 14 2016 20:54
yes
Francesco Biscani
@bluescarni
Nov 14 2016 20:55
are you sure about that or are you just expecting the worst? :)
Isuru Fernando
@isuruf
Nov 14 2016 20:55
just expecting the worst
Francesco Biscani
@bluescarni
Nov 14 2016 20:55
:) it's a good strategy
maybe then let's move the conda packages only on the osx builds?
Isuru Fernando
@isuruf
Nov 14 2016 20:58
yes
btw, I can recreate the segfault locally
Francesco Biscani
@bluescarni
Nov 14 2016 20:58
oh nice.. is that on a ubuntu system as well?
Isuru Fernando
@isuruf
Nov 14 2016 20:59
yes
Francesco Biscani
@bluescarni
Nov 14 2016 20:59
does it give any more info or just a straight segfault?
Isuru Fernando
@isuruf
Nov 14 2016 21:00
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6abd5d9 in std::ostream::sentry::sentry(std::ostream&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) backtrace
#0  0x00007ffff6abd5d9 in std::ostream::sentry::sentry(std::ostream&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00007ffff6abdd59 in std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x00007ffff6abe237 in std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x000000000040bb79 in piranha::impl::get_initial_thread_queues ()
    at /home/isuru/projects/piranha/src/detail/../thread_pool.hpp:230
#4  0x00000000004091c2 in __cxx_global_var_init.11(void) () at /home/isuru/projects/piranha/src/detail/../thread_pool.hpp:256
#5  0x000000000042cf4d in __libc_csu_init ()
#6  0x00007ffff60e77bf in __libc_start_main (main=0x409380 <main()>, argc=1, argv=0x7fffffffd978, 
    init=0x42cf00 <__libc_csu_init>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd968)
    at ../csu/libc-start.c:247
#7  0x00000000004092a9 in _start () at /home/isuru/projects/piranha/src/settings.hpp:63
Francesco Biscani
@bluescarni
Nov 14 2016 21:01
ahh interesting
so one change I made in the PR is that I am printing some text when the thread pool initializes
the thread pool is a global variable inited at startup
I am wondering if that's causing the difference in behaviour
let me check a second
could you try commenting out line 230 in thread_pool.hpp?
this line
Isuru Fernando
@isuruf
Nov 14 2016 21:05
Passes the tests
Francesco Biscani
@bluescarni
Nov 14 2016 21:05
lol well then
feel free to just erase the line
it was kinda for debugging purposes to check at what point in the startup procedure the thread pool is created, but in hindsight it's probably not a good idea to reference a global object such as cout in the init of another global object
Isuru Fernando
@isuruf
Nov 14 2016 21:07
When we used boost from conda the initializing order changed?
Francesco Biscani
@bluescarni
Nov 14 2016 21:10
I am not 100% sure. I think technically the order of initialization is undefined (i.e., implementation-defined), even though I seem to remember there might be some guarantee regarding the existence of cout. Maybe it's interacting badly with the fact that boost conda was compiled with an old libstdc++ version, or maybe it's a genuine bug
I think the matter is even more complicated by the fact that the thread_pool class is a template, so the order of init is completely undefined
but it looks like it might be possible to force the existence of cout by constructing a special sentinel object ios_base::Init (see second answer)
Francesco Biscani
@bluescarni
Nov 14 2016 21:15
awesome!
Isuru Fernando
@isuruf
Nov 14 2016 21:16
Going to sleep now. see you later
Francesco Biscani
@bluescarni
Nov 14 2016 21:16
we can keep it like this for the moment, if the need arise to print out something I will just try the init thingiebop and check it works
ok sleep well and thanks!