Hi Phil,

> Both appear to be Segmentation fault errors. Unfortunately I can't quite
> interpret what some of the test suite shell variables are meant to be and sh
> -xv didn't really expand any of them.

.. and both defects are relevant to test #104 -> because #115 is running
recursively some subset of tests (including the #104).

> bash-4.2# cd testsuite.dir/115
> bash-4.2# ./run
>
> > libtool: link: rm -f .libs/main.nm .libs/main.nmS .libs/main.nmT
> > [.. snip ..]
> > 104. exceptions.at:24: 104. C++ exception handling (exceptions.at:24):
> >      FAILED (exceptions.at:385)

See the log here ^^^^.

> Any advise on how to debug this would be appreciated as I just can't fathom
> out the testsuite variables eg "$lt_exe", it could well be just that the shel
> is broken rather than libtool since pretty much all the other tests went
> through fine.

You may not directly run "sh -xv".  The best approach how to debug shell
variables handled in scripts generated by autoconf's testsuite is to give the
'-x' parameter to the 'testsuite' script:

  $ cd tests
  $ ./testsuite 104 -x

Or possibly, you may use something like:

  make check TESTSUITEFLAGS='104 -x'

The same option you may use with generated './run' script in
'tests/testsuite.dir'.  See the './run --help' or './testsuite --help' text.

Pavel

Whoops,.. ok,. let me back up and redo the testing again. (doesn't help that I'm being plagued by a glibc signal-stack bug in mock either,..-grumble-)

Ok not terribly helpful but,..having beaten up elfutils in #891553 where all of it's segv problems were down to unaligned access, I'll wager that this will probably turn out to be similar.

--------------------------------------------------------------------------------

ugh lets see
libtool: link: g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mcpu=ultrasparc -Wl,-z -Wl,relro -o .libs/main main.o .libs/mainS.o -Wl,--export-dynamic  /builddir/build/BUILD/libtool-2.4.2/libltdl/.libs/dlopen.a l/.libs/liba.so l/.libs/libcommon.so /builddir/build/BUILD/libtool-2.4.2/tests/../libltdl/.libs/libltdlc.a -ldl -Wl,-rpath -Wl,/builddir/build/BUILD/libtool-2.4.2/tests/testsuite.dir/104/inst/lib
./exceptions.at:385: if $LIBTOOL --mode=execute -dlopen m/module.la "$lt_exe" ; then :; else lt_status=$?;                 test "X$host" != "X$build" && test -x "$lt_exe" && exit 77;     exit $lt_status; fi
stderr:
exceptions_in_prog
/builddir/build/BUILD/libtool-2.4.2/tests/testsuite.dir/at-groups/104/test-source: line 564:  9411 Segmentation fault      (core dumped) $LIBTOOL --mode=execute -dlopen m/module.la "$lt_exe"
stdout:
./exceptions.at:385: exit code was 139, expected 0
104. exceptions.at:24: 104. C++ exception handling (exceptions.at:24): FAILED (exceptions.at:385)
--------------------------------------------------------------------------------

I managed to strap strace around this
8544  execve("/builddir/build/BUILD/libtool-2.4.2/tests/testsuite.dir/104/.libs/lt-main", ["/builddir/build/BUILD/libtool-2."...], [/* 75 vars */]) = 0
...
8544  munmap(0xfffff8010020c000, 19748) = 0
8544  write(2, "exceptions_in_prog\n", 19) = 19
8544  --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0xfffff80100502558} ---
8544  +++ killed by SIGSEGV (core dumped) +++

so the SEGV (which according to strace flakes out with SEGV_ACCERR (/* Invalid permissions for mapped object.  */))
is coming from the lt-main binary execution. Sin the point of the exercise is to check on c++ error handling I'm not sure is the segv is somthing that was supposed to happen or not.

As for the message /builddir/build/BUILD/libtool-2.4.2/tests/testsuite.dir/at-groups/104/test-source: line 564 ... is interesting because it doesn't exist,.. well it might and have been deleted,.. checking on that now. Mmmm no don't see any obvious evidence of it being created.

bash-4.2# ls -l /builddir/build/BUILD/libtool-2.4.2/tests/testsuite.dir/at-groups/104/test-source
ls: cannot access /builddir/build/BUILD/libtool-2.4.2/tests/testsuite.dir/at-groups/104/test-source: No such file or directory
ls: cannot access /builddir/build/BUILD/libtool-2.4.2/tests/testsuite.dir/104/test-source: No such file or directory
bash-4.2# ls -l /builddir/build/BUILD/libtool-2.4.2/tests/testsuite.dir/104
total 332
-rw-r--r--. 1 root root    103 Jan  7 11:53 common.cpp
-rw-r--r--. 1 root root    744 Jan  7 11:53 common.h
-rw-r--r--. 1 root root    270 Jan  7 11:53 common.lo
-rw-r--r--. 1 root root  36080 Jan  7 11:53 common.o
drwxr-xr-x. 5 root root   4096 Jan  7 11:53 inst
drwxr-xr-x. 3 root root   4096 Jan  7 11:53 l
-rw-r--r--. 1 root root    352 Jan  7 11:53 lib.cpp
-rw-r--r--. 1 root root    636 Jan  7 11:53 lib.h
-rw-r--r--. 1 root root    261 Jan  7 11:53 lib.lo
-rw-r--r--. 1 root root  60936 Jan  7 11:53 lib.o
drwxr-xr-x. 3 root root   4096 Jan  7 11:53 m
-rwxr-xr-x. 1 root root   7900 Jan  7 11:53 main
-rw-r--r--. 1 root root   2422 Jan  7 11:53 main.cpp
-rw-r--r--. 1 root root 103272 Jan  7 11:53 main.o
-rw-r--r--. 1 root root    370 Jan  7 11:53 module.cpp
-rw-r--r--. 1 root root    400 Jan  7 11:53 module.h
-rw-r--r--. 1 root root    270 Jan  7 11:53 module.lo
-rw-r--r--. 1 root root  60928 Jan  7 11:53 module.o
-rwxr-xr-x. 1 root root   1447 Jan  7 11:53 run
-rw-r--r--. 1 root root   7154 Jan  7 11:53 testsuite.log


soooo possibility that it's writing to a non existant directory or at least trying to perhaps?

testsuite:
  at_test_source=$at_job_dir/test-source

dazed and confused.

Comparing with a x86_64 build
-----------------------------

spinning through the log,.. this seems to be the relevant section for x86_64.
-------------------------------------------------------------------------------
./exceptions.at:381: $LIBTOOL --mode=link --tag=CXX $CXX $CXXFLAGS $LDFLAGS -o main$EXEEXT       main.$OBJEXT l/liba.la l/libcommon.la -dlopen m/module.la $LIBLTDL -export-dynamic
++ /root/rpmbuild/BUILD/libtool-2.4.2/libtool --mode=link --tag=CXX g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wl,-z,relro -o main main.o l/liba.la l/libcommon.la -dlopen m/module.la /root/rpmbuild/BUILD/libtool-2.4.2/tests/../libltdl/libltdlc.la -export-dynamic
stderr:
stdout:
libtool: link: rm -f .libs/main.nm .libs/main.nmS .libs/main.nmT
libtool: link: (cd .libs && gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC -c -fno-builtin "mainS.c")
libtool: link: rm -f ".libs/mainS.c" ".libs/main.nm" ".libs/main.nmS" ".libs/main.nmT"
libtool: link: g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wl,-z -Wl,relro -o .libs/main main.o .libs/mainS.o -Wl,--export-dynamic  /root/rpmbuild/BUILD/libtool-2.4.2/libltdl/.libs/dlopen.a l/.libs/liba.so l/.libs/libcommon.so /root/rpmbuild/BUILD/libtool-2.4.2/tests/../libltdl/.libs/libltdlc.a -ldl -Wl,-rpath -Wl,/root/rpmbuild/BUILD/libtool-2.4.2/tests/testsuite.dir/104/inst/lib
++ lt_exe=./main
++ test -f ./main
++ lt_exe=./main
++ set +x
./exceptions.at:385: if $LIBTOOL --mode=execute -dlopen m/module.la "$lt_exe" ; then :; else lt_status=$?;                 test "X$host" != "X$build" && test -x "$lt_exe" && exit 77;     exit $lt_status; fi
++ /root/rpmbuild/BUILD/libtool-2.4.2/libtool --mode=execute -dlopen m/module.la ./main
++ :
stderr:
exceptions_in_prog
caught: exception in program
exceptions_in_lib
caught inside lib: exception in library
caught: exception from library
exceptions_in_module
caught inside module: exception in module
caught: exception from module
stdout:
++ set +x
./exceptions.at:387: $LIBTOOL --mode=install cp l/libcommon.la $libdir
-------------------------------------------------------------------------------

so the segv is most certainly not expected at all but it's being generated from the g++ executable. Fine,.. next up lets plug the g++ program into the debugger and see what on earth it thinks it's doing,.. heck this could well end up being a g++ bug and nothing to do with libtool at all.

> so the segv is most certainly not expected at all but it's being generated
> from the g++ executable. Fine,.. next up lets plug the g++ program into the
> debugger and see what on earth it thinks it's doing,.. heck this could well
> end up being a g++ bug and nothing to do with libtool at all.

Firstly, I would go for stepping through compiled program './main' inside
'testsuite.dir/104'.

You are able to re-run the compiled main program by libtool:

    $ cd testsuite.dir/104
    $ libtool --mode=execute -dlopen inst/mod/module.la ./inst/bin/main

Which is pretty much the same like:

    $ LD_LIBRARY_PATH=inst/mod/ ./inst/bin/main

~~> And so, you are able to run:

    $ LD_LIBRARY_PATH=inst/mod/ gdb ./inst/bin/main

Pavel

++ at_fn_check_prepare_dynamic 'if /builddir/build/BUILD/libtool-2.4.2/libtool --mode=execute -dlopen m/module.la "./main" ; then :; else lt_status=0;             test "Xsparc64-redhat-linux-gnu" != "Xsparc64-redhat-linux-gnu" && test -x "./main" && exit 77;         exit ; fi' exceptions.at:385
++ case $1 in
++ at_fn_check_prepare_trace exceptions.at:385
++ printf '%s\n' exceptions.at:385
++ at_check_trace=:
++ at_check_filter=:
++ :
++ :
++ at_status=139
++ at_failed=false
++ :
++ echo stderr:
stderr:
++ cat /builddir/build/BUILD/libtool-2.4.2/tests/testsuite.dir/at-groups/104/stderr
++ :
++ /builddir/build/BUILD/libtool-2.4.2/libtool --mode=execute -dlopen m/module.la ./main
exceptions_in_prog
/builddir/build/BUILD/libtool-2.4.2/tests/testsuite.dir/at-groups/104/test-source: line 565: 61893 Segmentation fault      (core dumped) $LIBTOOL --mode=execute -dlopen m/module.la "$lt_exe"
++ lt_status=139
-------------------------------------------------------------------------------

This eventually boils down to
[mockbuild@localhost 104]$  /builddir/build/BUILD/libtool-2.4.2/libtool --verbose --mode=execute -dlopen m/module.la ./.libs/lt-main
exceptions_in_prog
Segmentation fault (core dumped)


[mockbuild@localhost 104]$ gdb ./.libs/lt-main
(gdb) set environment LD_LIBRARY_PATH=m
(gdb) run
exceptions_in_prog

Program received signal SIGSEGV, Segmentation fault.
0xfffff8010061a558 in __frame_dummy_init_array_entry () from /lib64/libstdc++.so.6
(gdb) where
#0  0xfffff8010061a558 in __frame_dummy_init_array_entry () from /lib64/libstdc++.so.6
#1  0xfffff80100490988 in __cxxabiv1::__cxa_get_globals ()
    at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63
#2  0xfffff801004907cc in std::uncaught_exception ()
    at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:136
#3  0xfffff801004ccbe4 in ~sentry (this=0x7fefffff1b0, __in_chrg=<optimized out>)
    at /usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/ostream:429
#4  std::__ostream_insert<char, std::char_traits<char> > (__out=..., __s=<optimized out>, 
    __n=<optimized out>)
    at /usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/bits/ostream_insert.h:112
#5  0x000000000010321c in operator<< <std::char_traits<char> > (
    __s=0x1085f8 "exceptions_in_prog\n", __out=...)
    at /usr/lib/gcc/sparc64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ostream:533
#6  exceptions_in_prog () at main.cpp:30
#7  0x0000000000102e78 in main () at main.cpp:120

-------------------------------------------------------------------------------
Lets read that in order with some program text around it that might make some better sense:

#7  0x0000000000102e78 in main () at main.cpp:120
(gdb) list
115     int main (void)
116     {
117
118       LTDL_SET_PRELOADED_SYMBOLS();
119
120       if (exceptions_in_prog ())
121         return 1;
122       if (exceptions_in_lib ())
123         return 1;
124       if (exceptions_in_module ())

#6  exceptions_in_prog () at main.cpp:30
(gdb) list
25        return 0;
26      }
27
28      int exceptions_in_prog (void)
29      {
30        std::cerr << "exceptions_in_prog\n";
31        try {
32          foo ();
33        }
34        catch (exc e) {

#5  0x000000000010321c in operator<< <std::char_traits<char> > (
    __s=0x1085f8 "exceptions_in_prog\n", __out=...)
    at /usr/lib/gcc/sparc64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ostream:533
533             __ostream_insert(__out, __s,
(gdb) list
528         operator<<(basic_ostream<char, _Traits>& __out, const char* __s)
529         {
530           if (!__s)
531             __out.setstate(ios_base::badbit);
532           else
533             __ostream_insert(__out, __s,
534                              static_cast<streamsize>(_Traits::length(__s)));
535           return __out;
536         }
537

(gdb) down
#4  std::__ostream_insert<char, std::char_traits<char> > (__out=..., __s=<optimized out>,
    __n=<optimized out>)
    at /usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/bits/ostream_insert.h:112
112           return __out;
(gdb) list
107                   __throw_exception_again;
108                 }
109               __catch(...)
110                 { __out._M_setstate(__ios_base::badbit); }
111             }
112           return __out;
113         }
114
115       // Inhibit implicit instantiations for required instantiations,
116       // which are defined via explicit instantiations elsewhere.

#3  0xfffff801004ccbe4 in ~sentry (this=0x7fefffff1b0, __in_chrg=<optimized out>)
    at /usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/ostream:429
429             if (bool(_M_os.flags() & ios_base::unitbuf) && !uncaught_exception())
(gdb) list
424            *  @c flush() on the output stream.
425           */
426           ~sentry()
427           {
428             // XXX MT
429             if (bool(_M_os.flags() & ios_base::unitbuf) && !uncaught_exception())
430               {
431                 // Can't call flush directly or else will get into recursive lock.
432                 if (_M_os.rdbuf() && _M_os.rdbuf()->pubsync() == -1)
433                   _M_os.setstate(ios_base::badbit);

#2  0xfffff801004907cc in std::uncaught_exception ()
    at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:136
136       __cxa_eh_globals *globals = __cxa_get_globals ();
(gdb) list
131
132
133     bool
134     std::uncaught_exception() throw()
135     {
136       __cxa_eh_globals *globals = __cxa_get_globals ();
137       return globals->uncaughtExceptions != 0;
138     }

#1  0xfffff80100490988 in __cxxabiv1::__cxa_get_globals ()
    at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63
63      { return get_global(); }
(gdb) list
58      __cxxabiv1::__cxa_get_globals_fast() _GLIBCXX_NOTHROW
59      { return get_global(); }
60
61      extern "C" __cxa_eh_globals*
62      __cxxabiv1::__cxa_get_globals() _GLIBCXX_NOTHROW
63      { return get_global(); }
64
65
66      #else
67

#0  0xfffff8010061a558 in __frame_dummy_init_array_entry () from /lib64/libstdc++.so.6
(gdb) list
68      // Single-threaded fallback buffer.
69      static __cxa_eh_globals eh_globals;
70
71      #if __GTHREADS
72
73      static void
74      eh_globals_dtor(void* ptr)
75      {
76        if (ptr)
77          {

Umm,.. this is looking like a g++ bug and nothing to do with libtool, though poor libtool gets the blame since it's test program exposes it. Unfortunately my g++ knowledge extends only as far a spelling it and I tend to get rather blind when too many '__' and ':' chars are present. Also the gcc-*debuginfo* packages don't preserve MACRO definitions without -g3 so some prior internal knowledge of the compiler is required.

Outside of that, I suspect libtool is perfectly fine, I'l just have to drop the 104 and 115 tests when the architecture is sparc64 (possibly all of sparc)

This bug should probably be reassigned to gcc

Phil
=--=

> Outside of that, I suspect libtool is perfectly fine, I'l just have to
> drop the 104 and 115 tests when the architecture is sparc64 (possibly
> all of sparc)
>
> This bug should probably be reassigned to gcc

It really seems that the problem is outside of libtool, but it is quite
difficult to say that 'gcc' is guilty.

The reproducer would be:

  | $ cat main.cpp
  | #include <iostream>
  | int main()
  | {
  |     std::cerr << "we are able to write to stderr\n";
  | }
  | $ g++ main.cpp
  | $ ./a.out
  | we are able to write to stderr

If this does not work for you, libtool is innocent here.

Pavel

bash-4.2# g++ test.c
bash-4.2# ./a.out
we are able to write to stderr
Segmentation fault (core dumped)

I'd be happy to say libtool is innocent, it's simply showing up a weakness in g++ that needs attention by the compiler/libstdc++ folk

Tracking this externally now in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909

Sorry for wasting your time with this,.. (just when I originally hit it I couldn't make heads of tails of what the testsuite was trying to do.

Phil
=--=

(In reply to comment #7)

> [..] just when I originally hit it I couldn't make heads of tails of
> what the testsuite was trying to do.

Ok, np, closing NOTABUG.

Pavel

Just as a followup, it turns out this was all caused by glibc not having TLS support compiled in. For whatever reason the glibc configure script decided when it was being rebuilt that tls didn't exist even though it was. This is resolved by forcing '--with-tls' to the glibc configure

I guess a non zero result from `nm %{_lib}/ld-linux.so* | grep -c __tls_get_addr` would have been a way to flag it.. oh well, live and learn/look foolish