Bug#384565: [Monotone-devel] Re: Bug#384565: monotone - FTBFS: Build killed with signal 15
Hi, On Tue, 21 Nov 2006, Shaun Jackman wrote: It appears the BOOST_SP_DISABLE_THREADS is the source of monotone's cross-platform issues on Debian. Namely, that monotone fails to run (deadlock) on s390, hppa, sparc, mips, and mipsel, but runs fine on i386, amd64, ia64, alpha and powerpc [1]. [1] http://buildd.debian.org/build.php?pkg=monotone One suggested workaround (by Roman Zippel above) is to remove -DBOOST_SP_DISABLE_THREADS. The ChangeLog indicates that Nathaniel added this feature on 2005-09-30. So, my questions for the monotone mailing list are... 1. Is this more likely a bug in Boost or a bug in monotone? 2. Is it reasonable to workaround this bug by removing -DBOOST_SP_DISABLE_THREADS? 3. Is it worth going to the extra effort to only define -DBOOST_SP_DISABLE_THREADS on the platforms for which it works? I'll consider this last option if it means a performance improvement of at least, say arbitrarily, a factor of two or so. I think this should include the boost maintainer, there has to be some way to safely select the proper compile flags. At least the Debian packages provide a threaded and non-threaded version, but the .so link points to the threaded version by default. If both versions are supposed to be usable equally for non-threaded application it suggest a bug in boost... Anyway, until there is some mechanism to select this safely, it's probably better to compile the application with the same flags as the library was. bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384565: [Monotone-devel] Re: Bug#384565: monotone - FTBFS: Build killed with signal 15
On 11/22/06, Roman Zippel [EMAIL PROTECTED] wrote: ... 1. Is this more likely a bug in Boost or a bug in monotone? 2. Is it reasonable to workaround this bug by removing -DBOOST_SP_DISABLE_THREADS? 3. Is it worth going to the extra effort to only define -DBOOST_SP_DISABLE_THREADS on the platforms for which it works? I'll consider this last option if it means a performance improvement of at least, say arbitrarily, a factor of two or so. I think this should include the boost maintainer, there has to be some way to safely select the proper compile flags. At least the Debian packages provide a threaded and non-threaded version, but the .so link points to the threaded version by default. If both versions are supposed to be usable equally for non-threaded application it suggest a bug in boost... Anyway, until there is some mechanism to select this safely, it's probably better to compile the application with the same flags as the library was. I'll probably make an upload today. So, to be sure, I'm going to remove -DBOOST_SP_DISABLE_THREADS, but leave -DBOOST_DISABLE_THREADS? Is that correct, or are both defines to be removed? Thanks, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384565: [Monotone-devel] Re: Bug#384565: monotone - FTBFS: Build killed with signal 15
On Wed, Nov 22, 2006 at 09:54:42AM -0700, Shaun Jackman wrote: On 11/22/06, Roman Zippel [EMAIL PROTECTED] wrote: ... 1. Is this more likely a bug in Boost or a bug in monotone? 2. Is it reasonable to workaround this bug by removing -DBOOST_SP_DISABLE_THREADS? 3. Is it worth going to the extra effort to only define -DBOOST_SP_DISABLE_THREADS on the platforms for which it works? I'll consider this last option if it means a performance improvement of at least, say arbitrarily, a factor of two or so. I think this should include the boost maintainer, there has to be some way to safely select the proper compile flags. At least the Debian packages provide a threaded and non-threaded version, but the .so link points to the threaded version by default. If both versions are supposed to be usable equally for non-threaded application it suggest a bug in boost... Anyway, until there is some mechanism to select this safely, it's probably better to compile the application with the same flags as the library was. Right -- I tracked down the official word on this, which says: If your program is single-threaded and does not link to any libraries that might have used shared_ptr in its default configuration, you can #define the macro BOOST_SP_DISABLE_THREADS on a project-wide basis to switch to ordinary non-atomic reference count updates. (Defining BOOST_SP_DISABLE_THREADS in some, but not all, translation units is technically a violation of the One Definition Rule and undefined behavior. Nevertheless, the implementation attempts to do its best to accommodate the request to use non-atomic updates in those translation units. No guarantees, though.) ( http://www.boost.org/libs/smart_ptr/shared_ptr.htm ) So basically, if a program uses boost::shared_ptr, and also uses libraries that use boost::shared_ptr (including other boost libraries), then your program and those libraries must be compiled with the same BOOST_SP_DISABLE_THREADS setting. Unless you get lucky. (I guess it failing on less popular platforms in particular has something to do with the workarounds they mention in the second paragraph?) I'll probably make an upload today. So, to be sure, I'm going to remove -DBOOST_SP_DISABLE_THREADS, but leave -DBOOST_DISABLE_THREADS? Is that correct, or are both defines to be removed? That sounds correct. I suspect the reason _SP_ is split off as its own thing is exactly this... -- Nathaniel -- The problem...is that sets have a very limited range of activities -- they can't carry pianos, for example, nor drink beer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384565: [Monotone-devel] Re: Bug#384565: monotone - FTBFS: Build killed with signal 15
On Tue, Nov 21, 2006 at 02:04:07PM -0700, Shaun Jackman wrote: It appears the BOOST_SP_DISABLE_THREADS is the source of monotone's cross-platform issues on Debian. Namely, that monotone fails to run (deadlock) on s390, hppa, sparc, mips, and mipsel, but runs fine on i386, amd64, ia64, alpha and powerpc [1]. [1] http://buildd.debian.org/build.php?pkg=monotone One suggested workaround (by Roman Zippel above) is to remove -DBOOST_SP_DISABLE_THREADS. The ChangeLog indicates that Nathaniel added this feature on 2005-09-30. Right, makes sense. Thanks, Roman, for tracking this down. So, my questions for the monotone mailing list are... 1. Is this more likely a bug in Boost or a bug in monotone? It is sort of an unfortunate fact of life. But monotone is the simplest place to work around it. 2. Is it reasonable to workaround this bug by removing -DBOOST_SP_DISABLE_THREADS? Yes, that should work fine, with only some slowdown. 3. Is it worth going to the extra effort to only define -DBOOST_SP_DISABLE_THREADS on the platforms for which it works? I'll consider this last option if it means a performance improvement of at least, say arbitrarily, a factor of two or so. Debian's freeze and release of Etch is imminent, and I'd like to nail this bug before then. Otherwise, Etch will ship with the last bug-free version of monotone, which was 0.28. I have not had a chance to run any benchmarks. It's certainly less than a factor of 2. Shipping with 0.28 would not be the end of the world (at least it's post-0.26, unlike IIRC latest ubuntu!), but I would say go ahead and do it. (If anyone wants to run some benchmarks of how monotone's speed changes on some interesting operations with and without -DBOOST_SP_DISABLE_THREADS, that would be cool; we added it as something that would give _some_ win with no downside, so we've never actually bothered to check whether the win is even measurable.) -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384565: [Monotone-devel] Re: Bug#384565: monotone - FTBFS: Build killed with signal 15
Hi, I debugged the problem a bit and the problem seems to be the BOOST_SP_DISABLE_THREADS define and monotone being linked against the multithreaded boost libraries. boost and monotone have a different idea of the sp_counted_base class, so that it gets initialized within monotone non-threaded and boost later tries to lock some initialized memory and thus hangs. I recompiled monotone without the two boost defines and it seems to work fine. BTW when you generate a diff, please don't forget to touch Makefile.in somewhere, so the buildd won't attempt to regenerate it again from Makefile.am. bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384565: [Monotone-devel] Re: Bug#384565: monotone - FTBFS: Build killed with signal 15
Thank you for that trouble shooting! This is very useful information. Cheers, Shaun On 9/28/06, Roman Zippel [EMAIL PROTECTED] wrote: Hi, I debugged the problem a bit and the problem seems to be the BOOST_SP_DISABLE_THREADS define and monotone being linked against the multithreaded boost libraries. boost and monotone have a different idea of the sp_counted_base class, so that it gets initialized within monotone non-threaded and boost later tries to lock some initialized memory and thus hangs. I recompiled monotone without the two boost defines and it seems to work fine. BTW when you generate a diff, please don't forget to touch Makefile.in somewhere, so the buildd won't attempt to regenerate it again from Makefile.am. bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384565: [Monotone-devel] Re: Bug#384565: monotone - FTBFS: Build killed with signal 15
On Tuesday 26 September 2006 20:10, Shaun Jackman wrote: Both commands exist in fact. get_revision is used to generate package_full_revision.txt, and get_base_revision_id is used to generate package_revision.txt. Both of these commands require a monotone workspace though, and the tarball does not ship with one. monotone should give an error: But the tarfile comes with package_full_revision_dist.txt and package_revision.txt, and the build proces overwrites them only after successfully running the two commands mentioned above. Otherwise, it simply uses them as they are. - Thomas -- Thomas Moschny [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
