[Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance

[Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance

[antonio.poggiali at datalogic dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666

            Bug ID: 66666
           Summary: ARM compiled code segmentation fault on multiple
                    inheritance
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: antonio.poggiali at datalogic dot com
  Target Milestone: ---

Created attachment 35854
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35854&action=edit
Source files, compiled file, gcc output, etc.

Host system:
Linux MatrixPlatVb-lx-apoggiali 3.13.0-44-generic #73~precise1-Ubuntu SMP Wed
Dec 17 00:39:15 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Target system:
ARM cortex A5 (but same behavior on A9).
Linux sama5d4ek 3.18.0-linux4sam_5.0-alpha1 #1 Wed Jun 24 09:45:58 CEST 2015
armv7l GNU/Linux

Cross-compiler invocation and output:

Invoking: GCC C++ Compiler
arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -O0 -g3 -Wall -Wextra -c
-fmessage-length=0 --sysroot=<...> -march=armv7-a -mfloat-abi=hard
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -MMD -MP
-MF"liste.d" -MT"liste.d" -o "liste.o" "liste.cpp"
Finished building: 
liste.cpp

Invoking: GCC C++ Linker
arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ --sysroot=<...>
-march=armv7-a -mfloat-abi=hard -o "liste"  liste.o   
Finished building target: liste

Input file (liste.cpp):

#include <list>
#include <iostream>

class SmartObject
{
        public:

        virtual ~SmartObject(){
        }

        void method(void) {}
};

class IMyInterface
{
        public:

        virtual ~IMyInterface(){
        }

        virtual std::list<int> getList() = 0;
};

class MyObject :  public virtual IMyInterface, public SmartObject
{
        public:

        MyObject()
        {
                list.push_back(4);
                list.push_back(5);
        }

        virtual std::list<int> getList() {
                return list;
        }

        virtual ~MyObject(){
        }

        std::list<int> list;
};

int main()
{
        IMyInterface * ip = new MyObject();
        std::list<int> list_clone = ip->getList();
        // On size() I get a segmentation fault
        std::cout << list_clone.size() << std::endl;
        delete ip;
        return 0;
}

Stack at fault:
liste [C/C++ Remote Application]        
        list [1573] [cores: 0]  
                Thread [1] 1573 [core: 0] (Suspended : Signal :
SIGSEGV:Segmentation fault)     
                        std::_List_const_iterator<int>::operator++() at
stl_list.h:244 0x9738   
                        std::__distance<std::_List_const_iterator<int> >() at
stl_iterator_base_funcs.h:82 0x97d4       
                        std::distance<std::_List_const_iterator<int> >() at
stl_iterator_base_funcs.h:118 0x9430        
                        std::list<int, std::allocator<int> >::size() at
stl_list.h:887 0x9144   
                        main() at liste.cpp:50 0x8a14   

Comment:

The list obtained through ip->getList(); is incorrect: the tail pointer is
malformed. When size() is called the list is scanned to count the number of
elements. As the tail pointer is malformed the scan end condition is not met
and i get a segmentation fault (or an endless loop when optimization in on).

The same code works correctly on host system (x86_64-linux).

Notes:
Declaring "class MyObject : public virtual IMyInterface, public virtual
SmartObject" makes it work.
Also removing ~SmartObject() destructor makes it work.

In attachment source code and compiler outputs.

[Bug c++/66666] ARM compiled code segmentation fault on multiple inheritance

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|Linux sama5d4ek             |arm*-*-*
                   |3.18.0-linux4sam_5.0-alpha1 |
                   |#1 Wed Jun 24 09:45:58 CEST |
                   |2015 armv7l GNU/Linux       |
                 CC|                            |ramana at gcc dot gnu.org
               Host|Linux                       |x86_64-*-*
                   |MatrixPlatVb-lx-apoggiali   |
                   |3.13.0-44-generic           |
                   |#73~precise1-Ubuntu SMP Wed |
                   |Dec 17 00:39:15 UTC 2014    |
                   |x86_64 x86_64 x86_64        |
                   |GNU/Linux                   |

--- Comment #1 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Obvious "dumb" question given this is a cross-environnment - I'm assuming that
you have the same libstdc++ in both places ?

[Bug c++/66666] ARM compiled code segmentation fault on multiple inheritance

[antonio.poggiali at datalogic dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666

--- Comment #2 from Antonio Poggiali <antonio.poggiali at datalogic dot com> ---
(In reply to Ramana Radhakrishnan from comment #1)
> Obvious "dumb" question given this is a cross-environnment - I'm assuming
> that you have the same libstdc++ in both places ?

Yes, it is the same. I've just checked (again :-D).

[Bug c++/66666] ARM compiled code segmentation fault on multiple inheritance

[antonio.poggiali at datalogic dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666

--- Comment #3 from Antonio Poggiali <antonio.poggiali at datalogic dot com> ---
I've understand a little better the problem.
The compiler passes to std::list copy constructor a different address respect
to the destination variable. 
This causes size() call to fail (endless loop or segmentation fault).

Here you can find a simpler test-bench:

#include <iostream>

using namespace std;

class TestReference
{
        public:

        // This is a pointer to me
        const TestReference * _me;

        TestReference() {
                _me = this;
        }

        TestReference(const TestReference &obj)
        {
                _me = this;
        }
};

class SmartObject
{
        public:

        SmartObject(){}

        // removing this destructor makes it work
        virtual ~SmartObject(){}
};

class IMyInterface
{
        public:

        IMyInterface(){}

        // removing this destructor have no effect (fails anyway)
        virtual ~IMyInterface(){}

        virtual TestReference getTestReference() = 0;
};

// inheriting SmartObject virtually makes it work (but it is not feasible on
the overall application architecture)
class MyObject : public virtual IMyInterface, public SmartObject
{
        public:

        MyObject() : IMyInterface(), SmartObject() {}

        virtual TestReference getTestReference() {
                return testReference;
        }

        virtual ~MyObject(){
        }

        TestReference testReference;
};

int main()
{
        IMyInterface *ip = new MyObject();

        TestReference TestReference_local;
        std::cout << "object address " << &TestReference_local << std::endl;
        std::cout << "object address in constructor " <<
TestReference_local._me << std::endl;
        if (&TestReference_local != TestReference_local._me)
                std::cout << "warning! addresses are different!" << std::endl;

        TestReference TestReference_clone = ip->getTestReference();
        std::cout << "object address " << &TestReference_clone << std::endl;
        std::cout << "object address in copy constructor " <<
TestReference_clone._me << std::endl;
        if (&TestReference_clone != TestReference_clone._me)
                std::cout << "warning! addresses are different!" << std::endl;

        delete ip;
        return 0;
}

Basically I expect the object address in the copy constructor (this) to be the
same of the object in the calling code, but when the program fails it is not
so!

[Bug c++/66666] ARM compiled code segmentation fault on multiple inheritance

[antonio.poggiali at datalogic dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666

--- Comment #4 from Antonio Poggiali <antonio.poggiali at datalogic dot com> ---
I've understand a little better the problem.
The compiler passes to std::list copy constructor a different address respect
to the destination variable. 
This causes size() call to fail (endless loop or segmentation fault).

Here you can find a simpler test-bench:

#include <iostream>

using namespace std;

class TestReference
{
        public:

        // This is a pointer to me
        const TestReference * _me;

        TestReference() {
                _me = this;
        }

        TestReference(const TestReference &obj)
        {
                _me = this;
        }
};

class SmartObject
{
        public:

        SmartObject(){}

        // removing this destructor makes it work
        virtual ~SmartObject(){}
};

class IMyInterface
{
        public:

        IMyInterface(){}

        // removing this destructor have no effect (fails anyway)
        virtual ~IMyInterface(){}

        virtual TestReference getTestReference() = 0;
};

// inheriting SmartObject virtually makes it work (but it is not feasible on
the overall application architecture)
class MyObject : public virtual IMyInterface, public SmartObject
{
        public:

        MyObject() : IMyInterface(), SmartObject() {}

        virtual TestReference getTestReference() {
                return testReference;
        }

        virtual ~MyObject(){
        }

        TestReference testReference;
};

int main()
{
        IMyInterface *ip = new MyObject();

        TestReference TestReference_local;
        std::cout << "object address " << &TestReference_local << std::endl;
        std::cout << "object address in constructor " <<
TestReference_local._me << std::endl;
        if (&TestReference_local != TestReference_local._me)
                std::cout << "warning! addresses are different!" << std::endl;

        TestReference TestReference_clone = ip->getTestReference();
        std::cout << "object address " << &TestReference_clone << std::endl;
        std::cout << "object address in copy constructor " <<
TestReference_clone._me << std::endl;
        if (&TestReference_clone != TestReference_clone._me)
                std::cout << "warning! addresses are different!" << std::endl;

        delete ip;
        return 0;
}

Basically I expect the object address in the copy constructor (this) to be the
same of the object in the calling code, but when the program fails it is not
so!

on arm-linux:
object address 0xbeaf9be8
object address in constructor 0xbeaf9be8
object address 0xbeaf9bec
object address in copy constructor 0xbeaf9be4
warning! addresses are different!

on x64-linux:
object address 0x7ffff2be7410
object address in constructor 0x7ffff2be7410
object address 0x7ffff2be7420
object address in copy constructor 0x7ffff2be7420

[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666

Mikael Pettersson <mikpelinux at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpelinux at gmail dot com

--- Comment #6 from Mikael Pettersson <mikpelinux at gmail dot com> ---
Using the test case in comment #0, I can reproduce wrong-code on armv7l with
gcc-4.9, 4.8, and 4.7 (everything native, nothing cross).

4.9: -O0: SEGV, -O1/2/3/s: infinite loop
4.8/4.7: -O0: SEGV, -O1/2/3/s: prints 2 and exits 0

With gcc-5 and trunk, it prints 2 and exits 0 at all -O levels.

[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666

--- Comment #7 from Mikael Pettersson <mikpelinux at gmail dot com> ---
The test case in comment #0 stopped breaking on trunk with r221077, the fix for
PR65236 (a gcc-5 IPA regression).  Backporting r221077 to 4.9.3 unbreaks this
test case there.  However:

- I can't get this test case to fail anywhere except on ARM (x86_64, sparc,
m68k all work)
- The PR65236 test case doesn't fail with 4.9.3 on ARM

so I suspect a target-dependent issue here, and r221077 possibly just masks it.

[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance

[antonio.poggiali at datalogic dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666

--- Comment #8 from Antonio Poggiali <antonio.poggiali at datalogic dot com> ---
Hi all, I'm also trying the backport.

https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cgraphunit.c?revision=221077&view=markup&pathrev=221077

Is only this part of code to be backported?

Regards

[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance

[antonio.poggiali at datalogic dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666

--- Comment #9 from Antonio Poggiali <antonio.poggiali at datalogic dot com> ---
(In reply to Antonio Poggiali from comment #8)
> Hi all, I'm also trying the backport.
> 
> https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cgraphunit.
> c?revision=221077&view=markup&pathrev=221077
> 
> Is only this part of code to be backported?
> 
> Regards

Sorry, this code:

https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cgraphunit.c?r1=221077&r2=221076&pathrev=221077

I'm having cut and paste problems lately...

[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance

[antonio.poggiali at datalogic dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666

--- Comment #11 from Antonio Poggiali <antonio.poggiali at datalogic dot com> ---
(In reply to Mikael Pettersson from comment #10)
> (In reply to Antonio Poggiali from comment #9)
> > Sorry, this code:
> > 
> > https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cgraphunit.
> > c?r1=221077&r2=221076&pathrev=221077
> 
> Yes, but I'm not convinced it's the real fix.

Unfortunately I can't use gcc 5 (I'm trying but it's not so easy) so, up to
now, this "patch" is the only way to get my system working.

Do you think this bug will be fixed in a new release (e.g. 4.9.4)?

Thank you!

[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance

[antonio.poggiali at datalogic dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666

--- Comment #12 from Antonio Poggiali <antonio.poggiali at datalogic dot com> ---
Created attachment 35879
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35879&action=edit
Temporary patch for gcc 4.9.3

A temporary patch masking the problem on gcc 4.9.3

[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance

[jgreenhalgh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666

James Greenhalgh <jgreenhalgh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jgreenhalgh at gcc dot gnu.org

--- Comment #13 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> ---
Starting with my own set of silly questions while I try to narrow down what
environments I need to set up...

Your toolchain is arm-none-linux-gnueabi , but you build with -mfloat-abi=hard
- do you have suitable hard-float libraries on the target?

How was the toolchain configured
(arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -v)?

What userspace is running on the target?

[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance

[jgreenhalgh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666

James Greenhalgh <jgreenhalgh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-07-01
     Ever confirmed|0                           |1

--- Comment #15 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> ---
(In reply to Antonio Poggiali from comment #14)
> > 
> > Your toolchain is arm-none-linux-gnueabi , but you build with
> > -mfloat-abi=hard - do you have suitable hard-float libraries on the target?
> > 
> 
> I have only hard-float libraries and related system header files.
> 
> > How was the toolchain configured
> > (arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -v)?
> > 
> 
> <Snip>

Thanks, I've reproduced the failure using the configuration above.

Looks like we can drop most of the command line arguments and still tickle the
segmentation fault

> 
> > What userspace is running on the target?
> 
> Sorry but I don't understand the question. Could you explain a little?

Debian/Ubuntu/Android etc. I've been able to reproduce it with a Ubuntu 12.04.4
userspace. But I haven't yet understood the issue.

[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance

[antonio.poggiali at datalogic dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666

--- Comment #16 from Antonio Poggiali <antonio.poggiali at datalogic dot com> ---
(In reply to James Greenhalgh from comment #15)
> > 
> > > What userspace is running on the target?
> > 
> > Sorry but I don't understand the question. Could you explain a little?
> 
> Debian/Ubuntu/Android etc. I've been able to reproduce it with a Ubuntu
> 12.04.4 userspace. But I haven't yet understood the issue.

I'm using Yocto-generated Linux systems. I had the defect on systems build with
angstrom and also with poky. I had the defect on systems based on different HW
vendors systems (atmel & altera).

Currently i'm working on: Linux sama5d4ek
3.18.0-linux4sam_5.0-alpha1-00061-gfeb4121 #1 Tue Jun 30 11:14:11 CEST 2015
armv7l GNU/Linux

Do I answered you question?

[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance

[jgreenhalgh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66666

James Greenhalgh <jgreenhalgh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #17 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> ---
This feels very similar to pr65236. For your second testbench, we can look at
the output assembly for the fixup thunk for MyObject->getTestReference() for
arm:

---
_ZTv0_n16_N8MyObject16getTestReferenceEv:
        .fnstart
.LFB1058:
        @ args = 0, pretend = 0, frame = 16
        @ frame_needed = 1, uses_anonymous_args = 0
        stmfd   sp!, {r4, fp, lr}       @,
        .save {r4, fp, lr}
        .setfp fp, sp, #8
        add     fp, sp, #8      @,,
        .pad #20
        sub     sp, sp, #20     @,,
        str     r0, [fp, #-16]  @ .result_ptr, .result_ptr
        str     r1, [fp, #-20]  @ this, this
        ldr     r3, [fp, #-20]  @ vptr.4, this
        ldr     r3, [r3]        @ vtableaddr.5, *vptr.4_4
        sub     r3, r3, #16     @ vtableaddr.5, vtableaddr.5,
        ldr     r3, [r3]        @ vcalloffset.6, *vtableaddr.5_6
        mov     r2, r3  @ D.25213, vcalloffset.6
        ldr     r3, [fp, #-20]  @ tmp116, this
        add     r3, r3, r2      @ D.25214, tmp116, D.25213
        ldr     r4, [fp, #-16]  @ tmp117, .result_ptr
        sub     r2, fp, #28     @ tmp118,,
        mov     r0, r2  @, tmp118
        mov     r1, r3  @, D.25214
        bl      .LTHUNK0        @
        ldr     r3, [fp, #-28]  @ tmp119,
        str     r3, [r4]        @ tmp119, <retval>
        ldr     r0, [fp, #-16]  @, .result_ptr
        sub     sp, fp, #8      @,,
        @ sp needed     @
        ldmfd   sp!, {r4, fp, pc}       @
        .fnend
---

We allocate some stack space for the result (tmp118) and hand it off to the
called function as the return value. The copy constructor is invoked as a copy
to this temporary rather than to the stack slot reserved for
TestReference_clone. When we do return to main, we just do a simple word-wise
copy of the object.

As to your original bug, the root cause is similar, the copy constructor for
list wants to set up pointers to the final list node (I think). But we've given
it an address on the stack which we will soon clobber when we start executing.
You can see the mismatch in expectations if you build an empty list, and check
it is empty with list->empty rather than size.

(gdb) print this->_M_impl._M_node
$3 = {_M_next = 0xbeffef08, _M_prev = 0xbeffef08}
(gdb) print &this->_M_impl._M_node
$4 = (std::__detail::_List_node_base *) 0xbeffef2c

As to why this is target specific... My untested hunch is you'll see it on the
following targets { vax, stormy16, pa, nds32, mmix, frv, cris, arm } - those
being the targets which #define TARGET_ASM_CAN_OUTPUT_MI_THUNK
default_can_output_mi_thunk_no_vcall and go through the generic, heavyweight,
(and apparently broken) thunk code. Enabling return slot optimization would
protect these targets against the current issue - that of the thunk code
constructing a temporary object in a soon-to-die location on the stack.

With all that said, I think backporting Honza's trunk patch for pr65236 looks
like a reasonable thing to do. Though, I'm CCing Honza for his input.