Problem with Boost and GCC 4.1

[nobody]

There is a problem when using slots & trackable with GCC 4.1 - I don't know whether this is a GCC problem or a Boost problem, but it affects us (OpenWengo) on both Fedora Core and Feisty, since both distribute gcc 4.1.

I'm attaching a test case - the expected output is:

create A
fire SGN
A
create B
fire SGN
A
B
delete A
fire SGN
B
delete B
fire SGN
exit

This doesn't happen :) 

[nobody]

Logged In: NO 

For reference, this bug has been opened against Ubuntu: https://launchpad.net/ubuntu/+source/gcc-4.1/+bug/75724 and OpenSuse: https://bugzilla.novell.com/show_bug.cgi?id=228524

Dave.

[cepstein]

Logged In: YES 
user_id=36183
Originator: NO

When you say "this doesn't happen", what *does* happen?  Different output?  A crash?  Please be more specific.

Also, what version of Boost are you using?  I believe there has been at least one bug-fix to the signals library since 1.33.0, though I'm not sure if it is related:

http://boost.cvs.sourceforge.net/boost/boost/boost/signals/signal_template.hpp?r1=1.17&r2=1.17.2.1

Your test works for me on Ubuntu 6.06-LTS with Boost CVS as/of 2006-08-11 and these versions of gcc:

  gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
  gcc version 4.1.2

I don't think this is a gcc bug.

[nobody]

Logged In: NO 


What actually happens is undefined - you get jibberish after deleting A. It should select the slot B, but that doesn't happen.

Second info: this has also been created against GCC: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164

[nobody]

Logged In: NO 


As I said in a previous comment, what happens is indeterminate. On one run, you get this: http://phpfi.com/215193

The Boost version is a 1.33 - the one which comes with Edgy. From http://packages.ubuntu.com/edgy/libs/ it looks to be 1.33.1.

Dave.

[ficuz]

Logged In: YES 
user_id=344328
Originator: NO

I have this bug with Ubuntu/Edgy:
   boost 1.33.1-7ubuntu1
and
   gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)

Ludovico

[gladiac]

Logged In: YES 
user_id=880725
Originator: NO

The problem exists here with boost-1.33.1 and gcc (GCC) 4.1.2 20061115 (prerelease) (SUSE Linux)

Output:
-----------------
Starting program: /home/gladiac/workspace/tmp/testcase/a.out
create A
fire SGN
A
create B
fire SGN
A
B
delete A
fire SGN
A1��`�`ȱ`A�`�`AP�`�`�u��*p�`p�`!PL���*P�`1B!PL���*�`1 �`p�`��`10�`0�`Ȳ`!д`0�`A�`X�`P�`��`�`1d@�I@�`�:@!� @�`AP�`��`�u��*0�`0�`1��`1 �`p�`�`1!0�`AX�`��`�`�`@�`1d@�I@p�`�:@!� @0�`�

Program exited normally.

[tzlaine]

Logged In: YES 
user_id=729903
Originator: NO

I have verified this with gcc 4.1.0 (SuSE Linux), compiled and linked against Boost 1.33.1, then Boost 1.34 from a couple of moths ago.  It fails for both versions of Boost.  If I add "A = new Test("C", mySgn); B = new Test("D", mySgn);" right before "std::cerr << "fire SGN" << std::endl;", it segfaults nearly every time for me on the last mySgn() call.

[bk12]

Logged In: YES 
user_id=116622
Originator: NO

Here is an even simpler test case: when build with gcc 4.0 it outputs "Success", with gcc 4.1 it will output "Failure".

----
#include <iostream>
#include <boost/signal.hpp>
#include <boost/bind.hpp>

#include <stdlib.h>

class SomeObject : public boost::signals::trackable {
public:
	void function() {
		std::cerr << "Failure\n";
		exit(1);
	}
};

int main() {
	SomeObject* obj = new SomeObject;
	boost::signal<void ()> signal;
	signal.connect(boost::bind(&SomeObject::function, obj));
	delete obj;
	signal();

	std::cerr << "Success\n";
	return 0;
}
----

[Marshall Clow]

Assigned to "doug_gregor" instead of nonexistent user "dgregor"

[anonymous]

What's the status of this bug? Is it fixed in 1.34?

[Daryle Walker]

Sample file copied from the SourceForge version of this ticket

[anonymous]

Sorry for being impatient, but are there any news or any help needed? I'm using openSUSE-11.1

boost-1.36.0 gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]

The bug is still there. E.g the button_click.cpp example in svn fails printing two time 'OK!'.

[Michael Andres <ma@…>]

In case someone is listening: Is this really a linux/gcc problem? I'm asking because I don't see how/where the test could happen. (boost-1.36.0)

Looking at the slot ctor, neither get_inspectable_slot() nor the detail::bound_objects_visitor (trackable.hpp) seem to handle the case of a bound pointer to to member function.

If I'd add a few more decode() overloads to class bound_objects_visitor, I could catch those cases:

      template<class R, class T, class LT>
      void decode(const _bi::bind_t<R,_mfi::cmf0<R,T>, _bi::list1<LT> > & t, int) const
      {;}

      template<class R, class T, class A1, class LT, class L1>
      void decode(const _bi::bind_t<R,_mfi::cmf1<R,T,A1>, _bi::list2<LT,L1> > & t, int) const
      {;}

      ...

But I can't extract the 1st arg of the bind_t internal list in order to check whether it's a pointer of reference to a trackable seems to be a private member of bind_t).

May it be it's not a compiler problem, but simply not implemented?

[Daniel James]

I tried this on Ubuntu and it seems to have been fixed in 1.34.0. The output below shows it failing on 1.33.1 and passing on 1.34.0

daniel@bah:~$ ./boost_1_33_1/bin.v2/libs/signals/example/gcc-4.1/debug/test-gcc-boost 
create A
fire SGN
A
create B
fire SGN
A
B
delete A
fire SGN
A??R    ?R      ??R     !(?R    H?R     BR      !(?R    ??R     ~T?`?R  `?R      ??P?R  ??R     ??R     D?R     ??R     <?R     ??R     X?R     ?R      ??R    !??R     ??R     P?R     p?R     ?R      ???R    ?^?R    !(?R    x?R     ~T?8?R  8?R      ??(?R  ??R     ??R     <?R     ??R     !??R    ??R     (?R     H?R    ?
daniel@bah:~$ ./boost_1_34_0/bin.v2/libs/signals/example/gcc-4.1/debug/test-gcc-boost 
create A
fire SGN
A
create B
fire SGN
A
B
delete A
fire SGN
B
delete B
fire SGN
exit