bad code with boost::signals

[Ludovico Cavedon]

Binary package hint: g++-4.1

This version of gcc is producing bad code when using slots and trackable from boost.

In detail, automatic slot disconnection upon object destruction is not
working right.

I am attaching a test case and the correct output.

It is bad with:
gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)

but correct with
gcc-4.0 (GCC) 4.0.4 20060630 (prerelease) (Ubuntu 4.0.3-4)
and
gcc-3.4 (GCC) 3.4.6 (Ubuntu 3.4.6-3ubuntu1)

I am using Ubuntu/edgy

[Dave Neary (dneary)]

See https://bugzilla.novell.com/show_bug.cgi?id=228524 for the same bug against OpenSuse.

Dave.

[Dave-neary (dave-neary)]

Hi,

There is a problem when using slots & trackable from Boost 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 :)

What actually happens is that you get jibberish after "fire SGN" once you have deleted A, since the correct signal slot isn't selected. I'll attach the test case straight away.

[Dave-neary (dave-neary)]

Created attachment 13202
Test case to show problem with Boost and GCC 4.1

[Dave-neary (dave-neary)]

Additional bug tracker entries have been created against Ubuntu:
https://launchpad.net/ubuntu/+source/gcc-4.1/+bug/75724 and OpenSuse:
https://bugzilla.novell.com/show_bug.cgi?id=228524

And against Boost: http://sourceforge.net/tracker/index.php?func=detail&aid=1679990&group_id=7586&atid=107586

Dave.

[Dave Neary (dneary)]

I just opened a couple of bugs downstream against Boost: http://sourceforge.net/tracker/index.php?func=detail&atid=107586&aid=1679990&group_id=7586 and GCC: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164

[Rguenth (rguenth)]

And this duplicate doesn't add any useful information on top of what was entered
into the novell bugzilla. Nobody here is going to wade through boost to understand what is going on here.

[Claudio André (claudioandre.br)]

I tried the test case using Feisty (gcc 4.1.2) and:
- boost 1.33.1 (tar file from official site). Failed.
- boost 1.35 (SVN version). Succeed.

Nothing else was different.

[Pawel-sikora-9 (pawel-sikora-9)]

attached testcase works fine with vs2k3/boost-1.33/stlport.
it also works with g++-4.0.0/20050519(RH 4.0.0-8)/boost/libstdc++
on x86_64-gnu-linux. in the other. indeed, it fails with 4.1.2
and 4.2.0 (4.3 not tested).

[Matthias Klose (doko)]

reassign to boost, see the discussion in the suse task

[Vmpn (vmpn)]

Created attachment 13808
Test case without using boost

Please find attached a standalone test case without using boost. It based on my analysis of the boost functions affected.

The test runs differently when compiled with g++-3.4.6 (GCC) 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.10) and g++-4.1.2 (GCC) 4.1.2 (Gentoo 4.1.2)
versions of the GCC

If namespaces were removed from the test case, the issue did not seem to occur.

[Pinskia (pinskia)]

>The test runs differently when compiled with g++-3.4.6 (GCC) 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0,
> pie-8.7.10) and g++-4.1.2 (GCC) 4.1.2 (Gentoo 4.1.2) versions of the GCC

Yes and 4.1.x result is the correct according to the standard.
"We are in default template function" should be printed because the overloaded set for visit_each in visit_each (with two arguments) is the only one because the types are not in the namespace of bugsrus.

I have not looked into the original testcase yet but the new one is correct for 4.1 (see gcc-4.1/changes.html for more info).

[Cavedon-x (cavedon-x)]

Created attachment 13811
Patch to test.cpp, working with gcc 4.1

Adding the declaration of "our template function" before the "default template function without 3rd arg" makes gcc 4.1 behave the same way as 3.4.

[Vmpn (vmpn)]

Created attachment 13815
Test case fixed using forward declarations

Thank you for your help. I think I now have a better understanding of what is going on. As far as GCC is concerned the overriding visit_each template function dealing with MyData does not exist when it makes its decision regarding visit_each(v, data, 0); call.

I am attaching fixed (working with 4.1) text case that is more representative of the boost structure (to the best of my understanding). Also, I will be using it as a base for a follow up issue I ran into.

I am also including couple of relevant links for better context to this issue for anyone else who might stumble on this entry:

Two Phase looks ups and GCC:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11828
http://groups.google.com/group/comp.std.c++/msg/6a53b35efe39fee3
http://gcc.gnu.org/gcc-3.4/changes.html
http://gcc.gnu.org/onlinedocs/gcc/Name-lookup.html
http://developer.apple.com/releasenotes/DeveloperTools/RN-GCC4/index.html

IMHO, the changes are mentioned as early as gcc 3.4 but they did not seem to fully kick in until gcc 4.x.

Related boost email and change that I found:

http://lists.boost.org/Archives/boost/2006/04/103989.php
http://boost.cvs.sourceforge.net/boost/boost/boost/bind.hpp?r1=1.55&r2=1.56

Regards,

Vladimir

[Vmpn (vmpn)]

Created attachment 13816
Test case that does not call MyData visit_each (as expected)

Attaching a test case without forward declarations, that no longer calls MyData visit_each template function, as expected

[Vmpn (vmpn)]

Created attachment 13817
Test case that calls MyData visit_each without forward declaration

If the MydData visit_each is moved into the bugsrus::internal name space GCC now finds it, even though it is not declared upfront.

Regards,

Vladimir

[Pinskia (pinskia)]

The original issue was fixed upstream in boost 1.34 (according to the opensuse bug). So closing as moved. The sourceforge bug link for boost does not work any more.

[Redi (redi)]

Boost bug tracking moved to https://svn.boost.org/trac10/report and then to github. Boost.Signals was replaced by Boost.Signals2 years ago though.

Clang gives the same result as GCC. EDG does for C++11 and later, but behaves as the OP wants for --c++98 mode, suggesting there was a core DR related to this. Maybe something about the lookup and point of instantiation.

Anyway, the Boost change that fixed it seems to be:
https://github.com/boostorg/bind/commit/a87638486bda4bac1234753ef5930725eb3c31b4