From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9809 invoked by alias); 5 Mar 2004 05:05:45 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9802 invoked from network); 5 Mar 2004 05:05:43 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 5 Mar 2004 05:05:43 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 0652747D62; Thu, 4 Mar 2004 21:05:47 -0800 (PST) Date: Fri, 05 Mar 2004 05:05:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: [ob(ish)/committed] Fix SEGV in hppa_frame_cache Message-ID: <20040305050546.GC1226@gnat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2004-03.o/txt/msg00093.txt --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1877 I was happily testing what I hoped would be the latest version of the next/step patch replacing a complex condition by a frame ID comparison, when I discovered that it caused a few problems on HP/UX... But of course, HP/UX just got frame-ified! Here is a description of the first problem I looked into: (in gdb.base) % gdb (gdb) file coremaker (gdb) core-file corefile (gdb) up *** SEGV *** Ooops! What happens is that we hit the following code in hppa_frame_cache(): /* Yow! */ u = find_unwind_entry (frame_func_unwind (next_frame)); if (!u) return; Unfortunately, that return causes the return value to be undefined. And we later crash while trying to dereference this undefined value in hppa_frame_this_id(). So I fixed it with the attached patch. This fixed 8 tests. I didn't commit it to the 6.1 branch yet, as I wanted to wait for Andrew's comments first. Don't want to disturb the branch too much. There is also something that bothers me. If I understand this code well, it looks like we are going to abort the unwinding as soon as we hit a frame for which we can't find an associated function. Is that correct? That would be very unfortunate, especially after we manage to install the next/step patch I was testing; Once this patch is installed, the chances us GDB trying to unwind from an unknown location will be more important, no? If we don't know how to find our way out of there, then the next/step machinery will be weakened. Andrew, if you confirm my understanding is correct, I'll try to see if we can do better. 2004-03-04 J. Brobecker * hppa-tdep.c (hppa_frame_cache): Avoid undefined return value. Comments? Ok for the branch? (already committed in HEAD as, err, obvious - well, at least we don't crash anymore :-) Thanks, -- Joel --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="hppa-tdep.c.diff" Content-length: 537 Index: hppa-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/hppa-tdep.c,v retrieving revision 1.129 diff -u -p -r1.129 hppa-tdep.c --- hppa-tdep.c 27 Feb 2004 21:47:53 -0000 1.129 +++ hppa-tdep.c 5 Mar 2004 04:46:32 -0000 @@ -4617,7 +4617,7 @@ hppa_frame_cache (struct frame_info *nex /* Yow! */ u = find_unwind_entry (frame_func_unwind (next_frame)); if (!u) - return; + return (*this_cache); /* Turn the Entry_GR field into a bitmask. */ saved_gr_mask = 0; --OXfL5xGRrasGEqWY-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9809 invoked by alias); 5 Mar 2004 05:05:45 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9802 invoked from network); 5 Mar 2004 05:05:43 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 5 Mar 2004 05:05:43 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 0652747D62; Thu, 4 Mar 2004 21:05:47 -0800 (PST) Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: [ob(ish)/committed] Fix SEGV in hppa_frame_cache Message-ID: <20040305050546.GC1226@gnat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2004-03/txt/msg00093.txt.bz2 Message-ID: <20040319000900._ogOb7kmP7YpvUddIfoDZ-SxxNzZ8-mIprA0SbJ8Z5w@z> --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1877 I was happily testing what I hoped would be the latest version of the next/step patch replacing a complex condition by a frame ID comparison, when I discovered that it caused a few problems on HP/UX... But of course, HP/UX just got frame-ified! Here is a description of the first problem I looked into: (in gdb.base) % gdb (gdb) file coremaker (gdb) core-file corefile (gdb) up *** SEGV *** Ooops! What happens is that we hit the following code in hppa_frame_cache(): /* Yow! */ u = find_unwind_entry (frame_func_unwind (next_frame)); if (!u) return; Unfortunately, that return causes the return value to be undefined. And we later crash while trying to dereference this undefined value in hppa_frame_this_id(). So I fixed it with the attached patch. This fixed 8 tests. I didn't commit it to the 6.1 branch yet, as I wanted to wait for Andrew's comments first. Don't want to disturb the branch too much. There is also something that bothers me. If I understand this code well, it looks like we are going to abort the unwinding as soon as we hit a frame for which we can't find an associated function. Is that correct? That would be very unfortunate, especially after we manage to install the next/step patch I was testing; Once this patch is installed, the chances us GDB trying to unwind from an unknown location will be more important, no? If we don't know how to find our way out of there, then the next/step machinery will be weakened. Andrew, if you confirm my understanding is correct, I'll try to see if we can do better. 2004-03-04 J. Brobecker * hppa-tdep.c (hppa_frame_cache): Avoid undefined return value. Comments? Ok for the branch? (already committed in HEAD as, err, obvious - well, at least we don't crash anymore :-) Thanks, -- Joel --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="hppa-tdep.c.diff" Content-length: 537 Index: hppa-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/hppa-tdep.c,v retrieving revision 1.129 diff -u -p -r1.129 hppa-tdep.c --- hppa-tdep.c 27 Feb 2004 21:47:53 -0000 1.129 +++ hppa-tdep.c 5 Mar 2004 04:46:32 -0000 @@ -4617,7 +4617,7 @@ hppa_frame_cache (struct frame_info *nex /* Yow! */ u = find_unwind_entry (frame_func_unwind (next_frame)); if (!u) - return; + return (*this_cache); /* Turn the Entry_GR field into a bitmask. */ saved_gr_mask = 0; --OXfL5xGRrasGEqWY--