From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12340 invoked by alias); 11 May 2009 06:24:01 -0000 Received: (qmail 12325 invoked by uid 22791); 11 May 2009 06:23:57 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_61,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 May 2009 06:23:52 +0000 Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id n4B6NoGp000567 for ; Sun, 10 May 2009 23:23:50 -0700 Received: from qyk36 (qyk36.prod.google.com [10.241.83.164]) by wpaz24.hot.corp.google.com with ESMTP id n4B6NWJf025633 for ; Sun, 10 May 2009 23:23:48 -0700 Received: by qyk36 with SMTP id 36so3564184qyk.10 for ; Sun, 10 May 2009 23:23:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.99.206 with SMTP id v14mr199252qcn.50.1242023028468; Sun, 10 May 2009 23:23:48 -0700 (PDT) In-Reply-To: <6a8fced30905102154m5de0edb4w9ae77f6e9a3bb099@mail.gmail.com> References: <6a8fced30905101934j2aa94d27i210484a99a523ce5@mail.gmail.com> <834ovsz62r.fsf@gnu.org> <6a8fced30905102154m5de0edb4w9ae77f6e9a3bb099@mail.gmail.com> Date: Mon, 11 May 2009 06:24:00 -0000 Message-ID: <8ac60eac0905102323h49faa52eu72f03abc98223075@mail.gmail.com> Subject: Re: how to debug this error by gdb? From: Paul Pluzhnikov To: =?ISO-2022-JP?B?GyRCTEBrNBsoQg==?= Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-System-Of-Record: true 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: 2009-05/txt/msg00061.txt.bz2 2009/5/10 明覺 : > On Mon, May 11, 2009 at 11:11 AM, Eli Zaretskii wrote: >>> (gdb) run >>> Breakpoint 1, glXWaitX () at glxcmds.c:660 >>> (gdb) print psc->driScreen->waitX >>> $3 = (void (*)(__GLXDRIdrawable *)) 0x47206769666e6f63 >> ^^^^^^^^^^^^^^^^^^ >> This looks like ASCII text to me ("config G", little-endian). So I'd >> try to see if some code that runs before this place could overflow >> some buffer with plain text, and part of that text spilled into this >> pointer. > I do not understand, could give some advice about what to do? thanks The 'psc->driScreen' points to some structure, containing waitX element. That element was likely initialized to NULL at some point in execution, and may have been initialized to point to some function later on. Eli's conjecture (which I think is very likely correct) is that later still, some other code did a strcpy(x, y), where 'x' is at a lower memory address than psc->driScreen, and *does not have enough space* for string 'y', thus causing a buffer overflow. Further, string 'y' contained "... config G..." in it, and these characters happened to overwrite whatever bytes psc->driScreen->waitX used to contain. When you proceed to call "config G" as if it were a legal pointer, SIGSEGV results. The simplest way to track this down is probably to stop the application when 'psc->driScreen->waitX' is initalized, and set a watchpoint on it: (gdb) watch *(int **)&psc->driScreen->waitX If Eli's conjecture is true, above watchpoint will fire inside strcpy (or some similar libc function) exactly when waitX is being corrupted. An alternative (that I believe is also very likely) is that psc->driScreen is simply dangling. That is harder to isolate with GDB. If you run your program under Valgrind (which I strongly advise you to do), it should be able to tell you exactly what the problem is for either of the above guesses. Cheers, -- Paul Pluzhnikov