From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19069 invoked by alias); 22 Jun 2010 19:06:16 -0000 Received: (qmail 19057 invoked by uid 22791); 22 Jun 2010 19:06:15 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,TW_FD X-Spam-Check-By: sourceware.org Received: from gateout02.mbox.net (HELO gateout02.mbox.net) (165.212.64.22) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 Jun 2010 19:06:09 +0000 Received: from gateout02.mbox.net (gwo2-lo [127.0.0.1]) by gateout02.mbox.net (Postfix) with ESMTP id 8CBEF4BD3AD for ; Tue, 22 Jun 2010 19:06:07 +0000 (GMT) Received: from s1hub1.EXCHPROD.USA.NET [165.212.120.254] by gateout02.mbox.net via smtad (C8.MAIN.3.61T) with ESMTPS id XID684oFVTgH4738Xo2; Tue, 22 Jun 2010 19:06:07 -0000 X-USANET-Source: 165.212.120.254 IN slothman@electric-cloud.com s1hub1.EXCHPROD.USA.NET X-USANET-MsgId: XID684oFVTgH4738Xo2 Received: from [192.168.16.206] (74.85.3.82) by exchange.postoffice.net (10.120.220.31) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 22 Jun 2010 19:06:07 +0000 Message-ID: <4C2109B4.8070708@electric-cloud.com> Date: Tue, 22 Jun 2010 19:06:00 -0000 From: Max Kaehn User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Subject: Problem debugging core dump in gdb 7.1 on Solaris x86_64 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-06/txt/msg00101.txt.bz2 On a Solaris x86_64 machine: tempest-solaris% uname -a SunOS tempest-solaris 5.10 Generic_141445-09 i86pc i386 i86pc Solaris with a gdb 7.1 configured thusly: ./configure --build=x86_64-pc-solaris2.10 --host=x86_64-pc-solaris2.10 --target=x86_64-pc-solaris2.10 --prefix=/net/tools/gnu/gdb/7.1/i686_SunOS_64.5.10 --with-mpfr=/net/tools/mpfr/2.4.1/i686_SunOS_64.5.10 --with-gmp=/net/tools/gmp/4.3.1/i686_SunOS_64.5.10 --with-tcl=/net/tools/tcl/8.6b1/i686_SunOS_64.5.10/lib --with-tk=/net/tools/tcl/8.6b1/i686_SunOS_64.5.10/lib --with-expat --with-libexpat-prefix=/net/tools/expat/2.0.1/i686_SunOS_64.5.10 --with-curses --with-python=no --enable-tui --enable-64bit --enable-64-bit-bfd --with-libiconv-prefix=/net/tools/libiconv/1.13.1/i686_SunOS_64.5.10 --with-libintl-prefix=/net/tools/gnu/gettext/0.17/i686_SunOS_64.5.10 --enable-targets=i686-pc-solaris2.10,x86_64-pc-solaris2.10 and built using gcc 4.3.4 configured for i686-pc-solaris2.10 (which generates functioning amd64 binaries when I build with -m64), I can get a reasonable stack trace from the core dump from a simple program ("hello, world" + core dump): GNU gdb (GDB) 7.1 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later 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-pc-solaris2.10". For bug reporting instructions, please see: ... Reading symbols from /home/slothman/Projects/goodbye...done. [New LWP 1] Reading symbols from /net/tools/util/i686_SunOS.5.10/lib/amd64/libstdc++.so.6...done. Loaded symbols for /net/tools/util/i686_SunOS.5.10/lib/amd64/libstdc++.so.6 Reading symbols from /lib/amd64/libm.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/amd64/libm.so.2 Reading symbols from /net/tools/util/i686_SunOS.5.10/lib/amd64/libgcc_s.so.1...done. Loaded symbols for /net/tools/util/i686_SunOS.5.10/lib/amd64/libgcc_s.so.1 Reading symbols from /lib/amd64/libc.so.1...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread 1 (LWP 1)] Loaded symbols for /lib/amd64/libc.so.1 Reading symbols from /lib/amd64/ld.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/amd64/ld.so.1 Core was generated by `./goodbye'. Program terminated with signal 11, Segmentation fault. #0 0x0000000000400d17 in main (argc=1, argv=0xfffffd7fffdff848) at goodbye.cpp:7 7 *p = 0; but I've been unable to get a sensible stack trace out of a core dump from a more complex program: tempest-solaris% /net/tools/gnu/gdb/7.1/i686_SunOS_64.5.10/bin/gdb /net/chronic2nas/emake-slothman-main/out/i686_SunOS_64.5.10/ecloud/agent/ecagent /net/chronic2nas/emake-slothman-main/logs-201006211902-solx2-ea2/core GNU gdb (GDB) 7.1 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later 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-pc-solaris2.10". For bug reporting instructions, please see: ... Reading symbols from /net/chronic2nas/emake-slothman-main-201006211520/out/i686_SunOS_64.5.10/ecloud/agent/ecagent...done. [New LWP 1] [New LWP 2] [New LWP 3] [New LWP 4] [New LWP 5] Reading symbols from /usr/lib/amd64/ld.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/amd64/ld.so.1 Core was generated by `/opt/ecloud/i686_SunOS.5.10/bin/ecagent /opt/ecloud/i686_SunOS.5.10/bin/runagen'. Program terminated with signal 11, Segmentation fault. #0 0xfffffd7ffeac431c in ?? () (gdb) bt #0 0xfffffd7ffeac431c in ?? () Cannot access memory at address 0xfffffd7fffdfed30 (gdb) thread 2 [Switching to thread 2 (LWP 2)]#0 0xfffffd7ffeb2c8fa in ?? () (gdb) bt #0 0xfffffd7ffeb2c8fa in ?? () Cannot access memory at address 0xfffffd7ffe1f8dd8 (gdb) thread 3 [Switching to thread 3 (LWP 3)]#0 0xfffffd7ffeb27527 in ?? () (gdb) bt #0 0xfffffd7ffeb27527 in ?? () Cannot access memory at address 0xfffffd7ffdfffd68 (gdb) thread 4 [Switching to thread 4 (LWP 4)]#0 0xfffffd7ffeb27527 in ?? () (gdb) bt #0 0xfffffd7ffeb27527 in ?? () Cannot access memory at address 0xfffffd7ffde00e78 (gdb) thread 5 [Switching to thread 5 (LWP 5)]#0 0xfffffd7ffeb2c8fa in ?? () (gdb) bt #0 0xfffffd7ffeb2c8fa in ?? () Cannot access memory at address 0xfffffd7ffdbffc58 (gdb) info sharedlibrary >From To Syms Read Shared Object Library 0xfffffd7fff3c1010 0xfffffd7fff3e614e Yes (*) /usr/lib/amd64/ld.so.1 (*): Shared library is missing debugging information. ldd reports this binary pulls in about 30 shared libraries. I can load ecagent, type "break main", get a line number for it, and step through the code when it's live, but I still haven't managed to get gdb to figure out the core dump. Is anyone familiar with the arcana of Solaris x86? Thanks, Max