From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1516 invoked by alias); 12 Apr 2002 11:27:22 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 1509 invoked from network); 12 Apr 2002 11:27:20 -0000 Received: from unknown (HELO kerberos.suse.cz) (195.47.106.10) by sources.redhat.com with SMTP; 12 Apr 2002 11:27:20 -0000 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (SuSE SMTP server) with ESMTP id 3F30059D364; Fri, 12 Apr 2002 13:27:20 +0200 (CEST) Received: from suse.cz (leviathan.suse.cz [10.20.1.56]) by chimera.suse.cz (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id g3CBRKf32215; Fri, 12 Apr 2002 13:27:20 +0200 X-Authentication-Warning: chimera.suse.cz: Host leviathan.suse.cz [10.20.1.56] claimed to be suse.cz Message-ID: <3CB6C492.80108@suse.cz> Date: Fri, 12 Apr 2002 04:27:00 -0000 From: Michal Ludvig Organization: SuSE CR User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020327 X-Accept-Language: cs, cz, en MIME-Version: 1.0 To: Eli Zaretskii Cc: gdb Subject: Re: Strange segfaults of gdb References: <3CB5B5F1.7010809@suse.cz> <9743-Fri12Apr2002120839+0300-eliz@is.elta.co.il> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00206.txt.bz2 Eli Zaretskii wrote: >>It doesn't matter which program I run, what I want to print and if I >>then want invoke 'run', 'continue' or even 'si'. It segfaults. Core file >>doesn't give any reasonable informations. > > You mean, you cannot even tell from the core file where (inside what > function) GDB crashes? That'd be very strange indeed--what could > prevent you from getting att his information? Is the core file > corrupt or something? I can see the same information as if I run gdb from gdb. Anyway I treat them incorrect [see below]. > What if you run GDB under another GDB--can you see where does the > subordinate GDB crash then? (gdb) p 1 $1 = 1 (gdb) r Starting program: /root/mludvig/tst/xmmtest Program received signal SIGSEGV, Segmentation fault. 0x2a95ae759c in wait4 () at soinit.c:76 76 } (top-gdb) disassemble 0x2a95ae759c Dump of assembler code for function wait4: 0x2a95ae7590 : mov %rcx,%r10 0x2a95ae7593 : mov $0x3d,%rax 0x2a95ae759a : syscall 0x2a95ae759c : cmp $0xfffffffffffff001,%rax 0x2a95ae75a2 : jae 0x2a95ae75a5 0x2a95ae75a4 : retq 0x2a95ae75a5 : xor %rdx,%rdx 0x2a95ae75a8 : sub %rax,%rdx 0x2a95ae75ab : push %rdx 0x2a95ae75ac : callq 0x2a95a6fa30 0x2a95ae75b1 : pop %rdx 0x2a95ae75b2 : mov %rdx,(%rax) 0x2a95ae75b5 : or $0xffffffffffffffff,%rax 0x2a95ae75b9 : jmp 0x2a95ae75a4 0x2a95ae75bb : nop 0x2a95ae75bc : nop 0x2a95ae75bd : nop 0x2a95ae75be : nop 0x2a95ae75bf : nop End of assembler dump. So it appears like the segfault happend on 'cmp ,' instruction, which shouldn't be able to generate any exception at all. So I don't trust this information. Or do you have an idea how to interpret it? I don't say it's a bug in the gdb - it may be in the kernel, glibc or gcc as well, but everything else seems to work. Only gdb doesn't... May this be a memory corruption problem on the gdb side (perhaps it passes a wrong address to the syscall)? I'll try to use ElectricFence to see what happens. Is there somewhere a tutorial on how to examine/compare core files generated by gcore command? What should I look for? It's somehow difficult to debug a broken debugger using a broken debugger :-(( Michal Ludvig -- * SuSE CR, s.r.o * mludvig@suse.cz * +420 2 9654 5373 * http://www.suse.cz