C++ and "no data fields" when printing objects

C++ and "no data fields" when printing objects

[Stefano Sabatini]

Hi all,

It often occurrs to me to find such situatons when debugging:

(gdb) p ptr
$8 = {
  <> = {<No data fields>}, <No data fields>}

and everytime I wonder why the object is not represented meanignfully.

I previously made many researches on the subject, maybe I also already
asked on this list, and came out with the following man of the road
wisdom notions:

1) the problem shows up when you use inlined functions (but the
problem here seems to be related to printing *objects* rather than
step over functions).

2) in order to avoid that you need to use -ggdb -O0

3) it depends on some compiler magic which you really can't
understand

I'm quite sure that even using code compiled with gcc and -ggdb -O0
the abovementioned problem shows anyway.

I'd happily spend months studying the objcode structure and the gdb
internals, but unfortunately I can't, so I'm here to just ask if you
can reply to this questions:

1) which are the conditions under which the abovementioned problem
occurrs (e.g. with shared/static lib, with some arch, only with some
compiler+flags/binary format)?

2) how can I do to be sure not to encounter this problem when
debugging, i.e. which magic do I need to add to the compilation
command, even affecting code size/speed?

Thanks in advance, and thanks for the great tool.

Cheers.

Re: C++ and "no data fields" when printing objects

[Daniel Jacobowitz]

On Thu, Apr 02, 2009 at 03:28:11PM +0200, Stefano Sabatini wrote:
> 1) which are the conditions under which the abovementioned problem
> occurrs (e.g. with shared/static lib, with some arch, only with some
> compiler+flags/binary format)?

I have no idea; it doesn't happen to me.  In your searching did you
find any bugs in bugzilla describing this problem?  If not, do you
have any test where you can demonstrate it?

-- 
Daniel Jacobowitz
CodeSourcery

Re: C++ and "no data fields" when printing objects

[Stefano Sabatini]

On date Thursday 2009-04-02 14:52:20 -0400, Daniel Jacobowitz wrote:
> On Thu, Apr 02, 2009 at 03:28:11PM +0200, Stefano Sabatini wrote:
> > 1) which are the conditions under which the abovementioned problem
> > occurrs (e.g. with shared/static lib, with some arch, only with some
> > compiler+flags/binary format)?
> 
> I have no idea; it doesn't happen to me.  In your searching did you
> find any bugs in bugzilla describing this problem?  If not, do you
> have any test where you can demonstrate it?

OK I found #9222.

And here is how I can reproduce it, I'll try to work out a more
minimal issue case.

---------------8<------------------------------------------------
#include <iostream>

#include <ptlib.h>
#include <ptlib/safecoll.h>
#include <ptlib/pprocess.h>

class Test : public PProcess {
    PCLASSINFO(Test, PProcess)
    public:

    void Main(void);
};

class SafeThing : public PSafeObject {
public:
    SafeThing(int bar, int foo) : m_Bar(bar), m_Foo(foo) { }

    virtual void PrintOn(ostream &strm) const {
        strm << "foo(" << m_Foo << ") "
             << "bar(" << m_Bar << ") ";
    }

private:
    int m_Bar;
    int m_Foo;
};

PCREATE_PROCESS(Test)

void Test::Main(void)
{
    PSafePtr<SafeThing> ptr;
    
    cout << "ptr: " << ptr << endl;
    if (!!ptr)
        cout << *ptr << endl;

    return;
}
------------------------------8<-------------------------------

Informations on the system:

stefano@geppetto ~/s/ptlib> uname -a
Linux geppetto 2.6.26-1-686 #1 SMP Sat Oct 18 16:22:25 UTC 2008 i686 GNU/Linux
stefano@geppetto ~/s/ptlib> g++ --version
g++ (Debian 4.3.2-1) 4.3.2

Compilation command performed:
g++ -DPTRACING=1 -D_REENTRANT -D_GNU_SOURCE=1 -fno-exceptions
-I/home/stefano/include -I/usr/include/SDL -g -O0 -ggdb
-L/home/stefano/lib -lpt -lpthread -lsasl2 -lldap -llber -lldap_r
-lssl -lcrypto -lexpat -lSDL -lresolv -ldl psafeptr.cxx -o psafeptr

And here it is my gdb output:

(gdb) show version
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
(gdb) file psafeptr
(gdb) b Test::Main
Breakpoint 9 at 0x8049886: file psafeptr.cxx, line 35.
(gdb) r
[Thread debugging using libthread_db enabled]
[New Thread 0xb74236c0 (LWP 2490)]
[Switching to Thread 0xb74236c0 (LWP 2490)]

Breakpoint 7, main (argc=1, argv=0xbfc45474, envp=0xbfc4547c) at psafeptr.cxx:31
warning: Source file is more recent than executable.
(gdb) n

Breakpoint 8, Test::Main (this=0x9f4f000) at psafeptr.cxx:35
(gdb) p ptr
$15 = {
  <> = {<No data fields>}, <No data fields>}
(gdb) 

I'm using the latest SVN libpt (but I don't think it depends on the
version used, since it shows up also with a very ancient version of
it), and yes I compiled the lib with -ggdb -00 (compiled with make
debugshared).

Regards.

Re: C++ and "no data fields" when printing objects

[Stefano Sabatini]

On date Thursday 2009-04-02 14:52:20 -0400, Daniel Jacobowitz wrote:
> On Thu, Apr 02, 2009 at 03:28:11PM +0200, Stefano Sabatini wrote:
> > 1) which are the conditions under which the abovementioned problem
> > occurrs (e.g. with shared/static lib, with some arch, only with some
> > compiler+flags/binary format)?
> 
> I have no idea; it doesn't happen to me.  In your searching did you
> find any bugs in bugzilla describing this problem?  If not, do you
> have any test where you can demonstrate it?

OK I found #9222.

And here is how I can reproduce it, I'll try to work out a more
minimal issue case.

---------------8<------------------------------------------------
#include <iostream>

#include <ptlib.h>
#include <ptlib/safecoll.h>
#include <ptlib/pprocess.h>

class Test : public PProcess {
    PCLASSINFO(Test, PProcess)
    public:

    void Main(void);
};

class SafeThing : public PSafeObject {
public:
    SafeThing(int bar, int foo) : m_Bar(bar), m_Foo(foo) { }

    virtual void PrintOn(ostream &strm) const {
        strm << "foo(" << m_Foo << ") "
             << "bar(" << m_Bar << ") ";
    }

private:
    int m_Bar;
    int m_Foo;
};

PCREATE_PROCESS(Test)

void Test::Main(void)
{
    PSafePtr<SafeThing> ptr;
    
    cout << "ptr: " << ptr << endl;
    if (!!ptr)
        cout << *ptr << endl;

    return;
}
------------------------------8<-------------------------------

Informations on the system:

stefano@geppetto ~/s/ptlib> uname -a
Linux geppetto 2.6.26-1-686 #1 SMP Sat Oct 18 16:22:25 UTC 2008 i686 GNU/Linux
stefano@geppetto ~/s/ptlib> g++ --version
g++ (Debian 4.3.2-1) 4.3.2

Compilation command performed:
g++ -DPTRACING=1 -D_REENTRANT -D_GNU_SOURCE=1 -fno-exceptions
-I/home/stefano/include -I/usr/include/SDL -g -O0 -ggdb
-L/home/stefano/lib -lpt -lpthread -lsasl2 -lldap -llber -lldap_r
-lssl -lcrypto -lexpat -lSDL -lresolv -ldl psafeptr.cxx -o psafeptr

And here it is my gdb output:

(gdb) show version
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
(gdb) file psafeptr
(gdb) b Test::Main
Breakpoint 9 at 0x8049886: file psafeptr.cxx, line 35.
(gdb) r
[Thread debugging using libthread_db enabled]
[New Thread 0xb74236c0 (LWP 2490)]
[Switching to Thread 0xb74236c0 (LWP 2490)]

Breakpoint 7, main (argc=1, argv=0xbfc45474, envp=0xbfc4547c) at psafeptr.cxx:31
warning: Source file is more recent than executable.
(gdb) n

Breakpoint 8, Test::Main (this=0x9f4f000) at psafeptr.cxx:35
(gdb) p ptr
$15 = {
  <> = {<No data fields>}, <No data fields>}
(gdb) 

I'm using the latest SVN libpt (but I don't think it depends on the
version used, since it shows up also with a very ancient version of
it), and yes I compiled the lib with -ggdb -00 (compiled with make
debugshared).

Regards.