--enable-boost-threads flag
Greetings, If someone knows the answer off the top of their head, I would be interested in the answer. Otherwise, feel free to ignore this. Does the --enable-boost-threads flag for cctbx_sources/libtbx/configure.py do anything drastic besides include -pthread in the compiling and linking steps? I am trying to understand why I would get a free() error (for the shared_ptr to root_data) under the following situation: *) the iotbx_pdb shared library is configured without the --enable-boost-threads flag (on a linux box) *) sometimes reproducible from a test C++ program that is linked using -pthread even in the case when the program is as simple as loading a pdb file and creating the hierarchy. *) gcc 4.4.5 --Jeff Van Voorst
Hi Jeff,
Boost.Threads support in the cctbx was removed back in August (
http://phenix-online.org/pipermail/cctbxbb/2012-August/000468.html,
http://cctbx.svn.sourceforge.net/viewvc/cctbx?view=revision&revision=15762).
If you are using a recent copy of the sources then the libtbx configure
command should raise an error if you pass the now
defunct --enable-boost-threads option.
Cheers,
Richard
On 17 October 2012 15:03, Jeffrey Van Voorst
Greetings,
If someone knows the answer off the top of their head, I would be interested in the answer. Otherwise, feel free to ignore this.
Does the --enable-boost-threads flag for cctbx_sources/libtbx/**configure.py do anything drastic besides include -pthread in the compiling and linking steps?
I am trying to understand why I would get a free() error (for the shared_ptr to root_data) under the following situation: *) the iotbx_pdb shared library is configured without the --enable-boost-threads flag (on a linux box) *) sometimes reproducible from a test C++ program that is linked using -pthread even in the case when the program is as simple as loading a pdb file and creating the hierarchy. *) gcc 4.4.5
--Jeff Van Voorst ______________________________**_________________ cctbxbb mailing list [email protected] http://phenix-online.org/**mailman/listinfo/cctbxbbhttp://phenix-online.org/mailman/listinfo/cctbxbb
My question is of a slightly different nature. Specifically, what type of "magic" is enabled by --boost-enable-threads in the latest release of cctbx that allows the libiotbx_pdb.so library to be linked correctly to a simple program when that linking includes the "-pthread" flag? By simple, I mean a program that has two lines in the main function -- reading the PDB file and constructing the hierarchy. My goal is to try to understand the dependencies and why the simple program would have a memory corruption when libiotbx_pdb.so was not compiled using --boost-enable-threads. --Jeff On 10/17/12 5:28 PM, Richard Gildea wrote:
Hi Jeff,
Boost.Threads support in the cctbx was removed back in August (http://phenix-online.org/pipermail/cctbxbb/2012-August/000468.html, http://cctbx.svn.sourceforge.net/viewvc/cctbx?view=revision&revision=15762). If you are using a recent copy of the sources then the libtbx configure command should raise an error if you pass the now defunct --enable-boost-threads option.
Cheers,
Richard
As far as I can tell from the svn diff (
http://cctbx.svn.sourceforge.net/viewvc/cctbx?view=revision&revision=15762)
the only difference that passing --enable-boost-threads made was to include
the "-pthread" flag, and when not enabled the 'BOOST_DISABLE_THREADS'
option was passed instead to the compiler. I do not know if passing the
'BOOST_DISABLE_THREADS' option could cause a conflict when linking to a
program compiled with the -pthread option. Neither of these options are
passed to the compiler in the current cctbx.
Boost.Threads support was removed from the cctbx because it was only
experimental, and was superseded by better alternatives. Do you still
observe the same problem if you use a more recent version of the cctbx,
either svn or one of the nightly builds (http://cci.lbl.gov/builds/ - there
isn't really much distinction between "released" and "unreleased" builds)?
Cheers,
Richard
On 17 October 2012 16:56, Jeffrey Van Voorst
My question is of a slightly different nature. Specifically, what type of "magic" is enabled by --boost-enable-threads in the latest release of cctbx that allows the libiotbx_pdb.so library to be linked correctly to a simple program when that linking includes the "-pthread" flag? By simple, I mean a program that has two lines in the main function -- reading the PDB file and constructing the hierarchy.
My goal is to try to understand the dependencies and why the simple program would have a memory corruption when libiotbx_pdb.so was not compiled using --boost-enable-threads.
--Jeff
On 10/17/12 5:28 PM, Richard Gildea wrote:
Hi Jeff,
Boost.Threads support in the cctbx was removed back in August ( http://phenix-online.org/**pipermail/cctbxbb/2012-August/**000468.htmlhttp://phenix-online.org/pipermail/cctbxbb/2012-August/000468.html, http://cctbx.svn.sourceforge.**net/viewvc/cctbx?view=** revision&revision=15762http://cctbx.svn.sourceforge.net/viewvc/cctbx?view=revision&revision=15762). If you are using a recent copy of the sources then the libtbx configure command should raise an error if you pass the now defunct --enable-boost-threads option.
Cheers,
Richard
______________________________**_________________ cctbxbb mailing list [email protected] http://phenix-online.org/**mailman/listinfo/cctbxbbhttp://phenix-online.org/mailman/listinfo/cctbxbb
Hi Jeffrey,
Does the --enable-boost-threads flag for cctbx_sources/libtbx/configure.py do anything drastic besides include -pthread in the compiling and linking steps?
Nope as Richard explained.
I am trying to understand why I would get a free() error (for the shared_ptr to root_data) under the following situation: *) the iotbx_pdb shared library is configured without the --enable-boost-threads flag (on a linux box) *) sometimes reproducible from a test C++ program that is linked using -pthread even in the case when the program is as simple as loading a pdb file and creating the hierarchy. *) gcc 4.4.5
As Richard pointed out, Boost.Thread support has been removed but from your 3 points, it's clear that the latest cctbx won't cure your problem. There is nothing in the iotbx that have ever relied on Boost.Thread as far as I know, even less on PThread, at least not explicitly. By that I mean that it could be that some hot functions of the standard library have been optimized for multiprocessor in gcc 4.4.5, although I very highly doubt it. Could you try to compile your C++ program with -g and then find from where the free() error creeps up? I would also run that program through valgrind for good measure. Best wishes, Luc
Actually, Richard pointed out to me privately that as part of removing the support of Boost.Thread, I also remove the option -DBOOST_DISABLE_THREADS. Without it, some part of Boost supports threading, whatever that means. I did that on purpose, just to see if something would break, although I forgot to mention that in the commit message. It would again be very useful to know the full stacktrace to see whether that could be the problem. Luc
Ok, let me look into this a bit tomorrow. The issue is free() which gets an invalid address from a shared_ptr for root_data in iotbx_pdb when it is time for the whole pdb hierarchy to disappear. My main issue is I am not sure how to go about debugging shared_ptrs nor what architecture dependent flags or other voodoo (if any) is specified by -pthread. I can do the usual thing of printing out addresses and comparing them by eye, but I was hoping that there might be a better and more efficient method of debugging shared_ptrs. --Jeff
On Oct 18, 2012, at 11:21 AM, Jeffrey Van Voorst wrote:
Ok, let me look into this a bit tomorrow. The issue is free() which gets an invalid address from a shared_ptr for root_data in iotbx_pdb when it is time for the whole pdb hierarchy to disappear. My main issue is I am not sure how to go about debugging shared_ptrs nor what architecture dependent flags or other voodoo (if any) is specified by -pthread.
Could you try adding -DBOOST_DISABLE_THREADS to compile your C++ program? Luc
On 10/17/12 9:57 PM, Luc Bourhis wrote:
On Oct 18, 2012, at 11:21 AM, Jeffrey Van Voorst wrote:
Ok, let me look into this a bit tomorrow. The issue is free() which gets an invalid address from a shared_ptr for root_data in iotbx_pdb when it is time for the whole pdb hierarchy to disappear. My main issue is I am not sure how to go about debugging shared_ptrs nor what architecture dependent flags or other voodoo (if any) is specified by -pthread.
Could you try adding -DBOOST_DISABLE_THREADS to compile your C++ program?
Luc
I could do that. However, I would like to have just one copy of cctbx built, and be able to use the libiotbx_pdb.so library in both single and multithreaded code. The issue appears to me that the implementation of the boost smart_ptrs depends on defines set with respect to threads. My assumption is: if I compile cctbx with -DBOOST_DISABLE_THREADS and link to the libraries from programs that were not compiled with that flag, I will run into issues of having differing implementations of smart_ptrs. To follow up, I would need to try as you suggested. However, for the purposes of my package it is easiest for me to compile cctbx once. Therefore I need to compile cctbx without -DBOOST_DISABLE_THREADS and without -pthreads and see if I still run into the same problem. Am I correct in inferring that the latest SVN version of cctbx will configure (by default) to not use -pthreads and not use -DBOOST_DISABLE_THREADS? If you could point me to a good SCons tutorial or a good example script that has documentation, that would be very useful. --Jeff
Hi Jeffrey,
My assumption is: if I compile cctbx with -DBOOST_DISABLE_THREADS and link to the libraries from programs that were not compiled with that flag, I will run into issues of having differing implementations of smart_ptrs.
That was my assumption too indeed.
Am I correct in inferring that the latest SVN version of cctbx will configure (by default) to not use -pthreads and not use -DBOOST_DISABLE_THREADS?
Yes, indeed.
I would like to have just one copy of cctbx built, and be able to use the libiotbx_pdb.so library in both single and multithreaded code. [...] However, for the purposes of my package it is easiest for me to compile cctbx once.
Imho you should be able to achieve that by compiling the both of your program and the cctbx without BOOST_DISABLE_THREADS. The only influence of that flags is whether to disallow using atomic increment and decrement of the reference count used by shared ptr. Atomic in the sense of thread-safe, just to be crystal clear. Iiuc, without -D BOOST_DISABLE_THREADS (unless you define some other macros but I am sure you don't) for Intel processors, shared ptr should end up using increment and decrement written in Intel assembly language that use the Intel specific instruction "lock" to make those operations atomic. That code works however many threads are involved, the only issue being the performance degradation compared to non-atomic increments or decrements. But in practice, for what we do, this should be anecdotical.
If you could point me to a good SCons tutorial or a good example script that has documentation, that would be very useful.
Our SConscript's are the stuff of nightmares, agreed! I am not sure a generic SCons tutorial would be an useful considering how idiosyncratic our SConscript's are. There are two places to start, that you may already know, the SCons documentation and the SCons manpage. Eventually I reckon you just ask around on this forum every time you scratch your head for more than a few minutes! There are more than a handful of SCons expert split in 2 time zones, thus providing nearly a 24-hour service ;-) Best wishes, Luc
I am trying to use the set of commands to get cctbx from SVN (http://cctbx.sourceforge.net/current/installation.html#using-the-cctbx-svn-r...). However, either I am unable to follow the commands or something is not configured properly. I did the following steps: svn export https://cctbx.svn.sourceforge.net/svnroot/cctbx/trunk/libtbx/development/cct... /bin/csh cctbx_svn_getting_started.csh mkdir cctbx_build mv sources cctbx_sources cd cctbx_build python ../cctbx_sources/cctbx_project/libtbx/configure.py iotbx source setpaths.sh make Make fails almost immediately. I have listed the output from configure and the error from the make command on a gist (https://gist.github.com/3912960). I just checked: if I configure using mmtbx instead of iotbx then building the package works. --Jeff
It looks like the change Luc checked in yesterday regarding the
determination of the boost version has partially broken a build from
scratch. If you type the command:
libtbx.refresh
before issuing make then I think it should work.
Cheers,
Richard
On 18 October 2012 10:01, Jeffrey Van Voorst
I am trying to use the set of commands to get cctbx from SVN ( http://cctbx.sourceforge.net/**current/installation.html#** using-the-cctbx-svn-repositoryhttp://cctbx.sourceforge.net/current/installation.html#using-the-cctbx-svn-r... **). However, either I am unable to follow the commands or something is not configured properly.
I did the following steps: svn export https://cctbx.svn.sourceforge.**net/svnroot/cctbx/trunk/** libtbx/development/cctbx_svn_**getting_started.cshhttps://cctbx.svn.sourceforge.net/svnroot/cctbx/trunk/libtbx/development/cct... /bin/csh cctbx_svn_getting_started.csh mkdir cctbx_build mv sources cctbx_sources cd cctbx_build python ../cctbx_sources/cctbx_**project/libtbx/configure.py iotbx source setpaths.sh make
Make fails almost immediately. I have listed the output from configure and the error from the make command on a gist (https://gist.github.com/** 3912960 https://gist.github.com/3912960).
I just checked: if I configure using mmtbx instead of iotbx then building the package works.
--Jeff
______________________________**_________________ cctbxbb mailing list [email protected] http://phenix-online.org/**mailman/listinfo/cctbxbbhttp://phenix-online.org/mailman/listinfo/cctbxbb
Hi Jeffrey,
I am trying to use the set of commands to get cctbx from SVN [...] However, either I am unable to follow the commands or something is not configured properly.
my mistake sorry as I introduced a subtle bug a few days ago. I have just committed a fix. Best wishes, Luc
Ok, this is fixed sufficiently well on my end. Thanks for your help and comments. --Jeff
Am Freitag 19 Oktober 2012 13:55:31 schrieb Jeffrey Van Voorst:
Ok, this is fixed sufficiently well on my end. Thanks for your help and comments.
I can confirm this fixing a clean build for me as well. With regards, Dipl. Phys. Jan M. Simons Institute of Crystallography RWTH Aachen University
participants (4)
-
Jan Marten Simons
-
Jeffrey Van Voorst
-
Luc Bourhis
-
Richard Gildea