relocation error for c++::sstream

[Hans van den Bogert]

Running the following under DCE

#include <sstream>
#include <iostream>


main(int argc, char**  argv) {
  using std::istringstream;
  using std::string;
  istringstream is;

  int port;
  string s("3000");
  is.str(s);
  is.clear();
  is >> port;

  std::cout << port << std::endl;
}
It throws a bad cast in the  "  is >> port;" line. I'm not exactly a gdb guru, but that was what I was able to figure out by 'stepi'ing. If you simply step in the aforementioned line -- at least in my environment -- it doesn't actually go into the libstdc++  but gives the following:

./waf --run dce-processingandsleep --command-template="gdb --args %s"
Waf: Entering directory `/home/gandalf/src/dce/source/ns-3-dce/build'

--------------------------------------------------------------------
 Python bindings compilation
--------------------------------------------------------------------
[ 10/320] lib/pkgconfig/libns3-dev-netlink-debug.pc:  -> build/lib/pkgconfig/libns3-dev-netlink-debug.pc
[110/320] lib/pkgconfig/libns3-dev-dce-debug.pc:  -> build/lib/pkgconfig/libns3-dev-dce-debug.pc
Waf: Leaving directory `/home/gandalf/src/dce/source/ns-3-dce/build'
'build' finished successfully (0.363s)
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 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 "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/gandalf/src/dce/source/ns-3-dce/build/myscripts/processingandsleep/bin/dce-processingandsleep...done.
(gdb) run
Starting program: /home/gandalf/src/dce/source/ns-3-dce/build/myscripts/processingandsleep/bin/dce-processingandsleep
Traceback (most recent call last):
  File "/usr/lib/debug/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19-gdb.py", line 63, in <module>
    from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named 'libstdcxx'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGUSR1, User defined signal 1.
[New Thread 0x7ffff46f4700 (LWP 9314)]
/home/gandalf/src/dce/source/ns-3-dce/build/myscripts/processingandsleep/bin/dce-processingandsleep: relocation error: elf-cache/0/libgcc_s.so.1: symbol dl_iterate_phdr, version GLIBC_2.2.5 not defined in file 0001.so.6 with link time reference
[Thread 0x7ffff46f4700 (LWP 9314) exited]
[Inferior 1 (process 9288) exited with code 0177]

[Hans van den Bogert]

I've been able to track this further to:
/build/buildd/gcc-4.8-4.8.2/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_ios.tcc (install debugging symbols and source for libstdc++, this path is default under ubuntu 14.04)

  has_facet<__num_get_type>(__loc), true))

Is failing, I'm not sure how much further this debugging rabithole goes but I hope that Hajime is able to solve this now, since I'm pretty sure it has to do with locale settings.

[Hans van den Bogert]

Once more narrowed down to:

Here is the stacktrace for the interesting part:
#0  std::locale::locale (this=0x7ffff46f3bc0) at ../../../../../src/libstdc++-v3/src/c++98/locale_init.cc:221
#1  0x00007fffef460968 in std::ios_base::_M_init (this=0x7ffff46f3d00) at ../../../../../src/libstdc++-v3/src/c++98/ios_locale.cc:44
#2  0x00007fffef46e9a1 in std::basic_ios<char, std::char_traits<char> >::init (this=0x7ffff46f3d00, __sb=0x0)
    at /build/buildd/gcc-4.8-4.8.2/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_ios.tcc:129
#3  0x00007fffef48bd2f in basic_istream (
    __vtt_parm=0x7fffef6dc188 <VTT for std::basic_istringstream<char, std::char_traits<char>, std::allocator<char> >+8>, this=0x7ffff46f3ca0,
    __in_chrg=<optimized out>) at /build/buildd/gcc-4.8-4.8.2/build/x86_64-linux-gnu/libstdc++-v3/include/istream:608
#4  std::basic_istringstream<char, std::char_traits<char>, std::allocator<char> >::basic_istringstream (this=0x7ffff46f3ca0, __str=...,
    __mode=std::_S_in, __in_chrg=<optimized out>, __vtt_parm=<optimized out>)
    at /build/buildd/gcc-4.8-4.8.2/build/x86_64-linux-gnu/libstdc++-v3/include/sstream:328
#5  0x00007fffef1eff81 in main (argc=2, argv=0x646fa0) at /home/gandalf/BTSync/bugs/dce/istringstream/istringstream.cc:12
#6  0x00007ffff7a7dbaf in ns3::DceManager::DoStartProcess (context=0x647200) at ../model/dce-manager.cc:282
#7  0x00007ffff7b03694 in ns3::TaskManager::Trampoline (context=0x647020) at ../model/task-manager.cc:274
#8  0x00007ffff7aff6e5 in ns3::PthreadFiberManager::Run (arg=0x6474f0) at ../model/pthread-fiber-manager.cc:402
#9  0x00007ffff4cc7182 in start_thread (arg=0x7ffff46f4700) at pthread_create.c:312
#10 0x00007ffff49f3fbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

And the interesting part is this:
221         _M_impl = _S_global;
(gdb)
222         if (_M_impl == _S_classic)
(gdb) print _M_impl
$56 = (std::locale::_Impl *) 0x7fffef6f4e00 <(anonymous namespace)::c_locale_impl>
(gdb) print _S_classic
$57 = (std::locale::_Impl *) 0x7ffff53f5e00 <(anonymous namespace)::c_locale_impl>

Whereas the 2 variables would point to the same when running the program without NS-3/DCE, which one would expect after the assignment on line 221

Because _M_impl is pointing to something else, though it looks like a locale object, its locale facets are wrong, consequently the inputstream in the example code then fails because it lacks a certain facet needed by the inputstringstream.

Hope this helps

[Hajime Tazaki]

after applying my previous patch, it shows your sample
program runs but generate unexpected output.

> >> std::cout << port << std::endl;

where this line generate "1" to the stdout file while normal
execution gives "3000" as expected.

I also guess this might be a locale object issue and seems
to be global symbol handling issue of DCE. I will look at it
more detail.


-- Hajime

At Thu, 11 Sep 2014 09:22:21 -0700 (PDT),

Hans van den Bogert wrote:
>

> [1 <text/plain; UTF-8 (7bit)>]

> --
> You received this message because you are subscribed to the Google Groups "ns-3-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
> To post to this group, send email to ns-3-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ns-3-users.
> For more options, visit https://groups.google.com/d/optout.
> [2 <text/html; UTF-8 (quoted-printable)>]
>

[Hans van den Bogert]

It seems related to symbol handling indeed, I just tested with the DLM loader and the result is '3000' as expected.

Is this a bug in Cooja?

[Hajime Tazaki]

At Tue, 16 Sep 2014 04:45:01 -0700 (PDT),

Hans van den Bogert wrote:
>
> [1 <text/plain; UTF-8 (7bit)>]

> It seems related to symbol handling indeed, I just tested with the DLM
> loader and the result is '3000' as expected.
>
> Is this a bug in Cooja?

Hi,

yes, it seems to be a bug.

Indeed, we have an issue of Cooja, which has never fixed so
far due to the tricky way it uses.

https://www.nsnam.org/bugzilla/show_bug.cgi?id=1676

It would be nice if you could fill another bugzilla entry
for the particular issue you faced.

thanks.
-- Hajime

> > an email to ns-3-users+...@googlegroups.com <javascript:>.

> > > To post to this group, send email to ns-3-...@googlegroups.com

> > <javascript:>.

[Hans van den Bogert]

Ok, done:

https://www.nsnam.org/bugzilla/show_bug.cgi?id=1988

[Hajime Tazaki]

At Thu, 18 Sep 2014 00:16:17 -0700 (PDT),

Hans van den Bogert wrote:
>
> [1 <text/plain; UTF-8 (7bit)>]

> Ok, done:
>
> https://www.nsnam.org/bugzilla/show_bug.cgi?id=1988

thanks !

-- Hajime

[Hans van den Bogert]

Hajime,

This bug is driving me nuts because inputstreams are like.. everywhere in C++, unfortunately I can't use DLM because it doesn't have python bindings and thus can't be used from within NEPI.

I'm willing to spend some time to solve this, but I have no idea where to begin, do you have any clue? Or can we ask some DCE ex-maintainer?

Furthermore, do you think my findings in GDB  are any indication of the problem?