public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* RE: preprocessor/6084: cpp Segmentation Fault
@ 2002-03-29 11:36 Gerwin, Joshua A
0 siblings, 0 replies; 20+ messages in thread
From: Gerwin, Joshua A @ 2002-03-29 11:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/6084; it has been noted by GNATS.
From: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
To: "'neil@gcc.gnu.org'" <neil@gcc.gnu.org>,
"'gcc-bugs@gcc.gnu.org'"<gcc-bugs@gcc.gnu.org>,
"'gcc-prs@gcc.gnu.org'" <gcc-prs@gcc.gnu.org>,
"'joshg@hf.intel.com'" <joshg@hf.intel.com>,
"'nobody@gcc.gnu.org'"<nobody@gcc.gnu.org>,
"'rnesius@ichips.intel.com'"<rnesius@ichips.intel.com>,
"Nguyen, Tuan" <tuan.nguyen@intel.com>,
"'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>
Cc:
Subject: RE: preprocessor/6084: cpp Segmentation Fault
Date: Fri, 29 Mar 2002 11:35:17 -0800
> -----Original Message-----
> From: neil@gcc.gnu.org [mailto:neil@gcc.gnu.org]
> Sent: Friday, March 29, 2002 12:20 AM
> To: gcc-bugs@gcc.gnu.org; gcc-prs@gcc.gnu.org; joshg@hf.intel.com;
> nobody@gcc.gnu.org; rnesius@ichips.intel.com; tuan.nguyen@intel.com
> Subject: Re: preprocessor/6084: cpp Segmentation Fault
>
>
> Synopsis: cpp Segmentation Fault
>
> State-Changed-From-To: open->feedback
> State-Changed-By: neil
> State-Changed-When: Fri Mar 29 00:20:22 2002
> State-Changed-Why:
> Changed to category preprocessor; not a front end issue.
>
> Quite a surpise to me, too. I take pride in cpp not
> segfaulting 8-)
>
> Could you give me a testcase? I can't reproduce it with
> the information supplied.
> Or, could you try 3.0.4? There was a segfault fixed in the
> later 3.0 cycle, triggered by a combination of command
> line options, but I'm not sure which 3.0.x got it.
> Judging by your command line, I suspect it is caused by
> a certain combination of switches; can you reproduce it
> on a simple file like #include <stdio.h> or something?
>
> Alternatively, if you can't produce a simple testcase,
> but can get it to happen on Linux, then please send me the
> files so I can track this down, or tell me where it happens
> when you're debugging the cpp0 binary.
>
> Thanks!
>
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&
database=gcc&pr=6084
Sorry about the category thing, I didn't notice a preprocessor category on
the submit form.
The first sighting of the cpp segfault was in a troublesome build of op.c in
the vanilla perl 5.6.1 distribution from CPAN. However, you need not go
there. Using the same command line options, I can get it to segfault
without any source at all, simply by using ^D for stdin. Since an empty
file may be aesthetically unsatisfying, I submit the following:
$ cat ../../../../accessories/hello.c
#include <stdio.h>
#ifdef MATHTEST
#include <math.h>
#endif
main() {
float X;
printf("Hello, World! \n");
#ifdef MATHTEST
X = sqrt(4);
printf("the sqrt of 4 is %f \n", X);
#endif
}
$ /(path/to)/gcc/3.0.3-64/bin/cpp -DPERL_CORE -fno-strict-aliasing
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -mcpu=v9 -m64 -Wa,-xarch=v9 -O3
-m64 -dM -dD -dI -v ../../../../accessories/hello.c
Reading specs from
/(path/to)/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/specs
Configured with: ../gcc-3.0.3/configure --host=sparcv9-sun-solaris2
--prefix=
/(path/to)/gcc/3.0.3-64 --with-as=/usr/ccs/bin/as
--with-nm=/(path/to)/gcc/3.0.3-64/bin/nm --with-ld=/usr/ccs/bin/ld
Thread model: posix
gcc version 3.0.3
/(path/to)/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0 -lang-c
-v -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__
-D__svr4__ -D__SVR4 -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4
-D__OPTIMIZE__ -D__STDC_HOSTED__=1 -dM -dD -dI -D__SIZE_TYPE__=long unsigned
int -D__PTRDIFF_TYPE__=long int -D__WCHAR_TYPE__=int -D__WINT_TYPE__=int
-D__arch64__ -Acpu=sparc64 -Amachine=sparcv9 -D__sparcv9 -DPERL_CORE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 ../../../../accessories/hello.c
GNU CPP version 3.0.3 (cpplib) (sparc)
ignoring nonexistent directory
"/(path/to)/gcc/3.0.3-64/sparcv9-sun-solaris2/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/(path/to)/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/include
/usr/include
End of search list.
cpp: Internal error: Segmentation Fault (program cpp0)
Please submit a full bug report.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
A minor experiment in option removal shows that the problem is potentially
tied to the
-dD tag. Compare:
$ /(path/to)/gcc/3.0.3-64/bin/cpp -mcpu=v9 -m64 -Wa,-xarch=v9 -O3 -m64 -dM
-dD ../../../../accessories/hello.c
cpp: Internal error: Segmentation Fault (program cpp0)
Please submit a full bug report.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
$ /usr/intel/pkgs/gcc/3.0.3-64/bin/cpp -mcpu=v9 -m64 -Wa,-xarch=v9 -O3 -m64
-dM ../../../../accessories/hello.c
#define __USER_LABEL_PREFIX__
#define _LONG_LONG_HTOL
#define __SIZE_TYPE__ long unsigned int
#define _LONG_ALIGNMENT 8
#define _LONG_DOUBLE_ALIGNMENT 16
#define P_tmpdir "/var/tmp/"
#define _SSIZE_T
#define __arch64__ 1
#define __PTRDIFF_TYPE__ long int
#define _FILE_OFFSET_BITS 64
#define _ALIGNMENT_REQUIRED 1
#define __HAVE_BUILTIN_SETJMP__ 1
#define _SHORT_ALIGNMENT 2
#define SEEK_SET 0
#define _DOUBLE_ALIGNMENT 8
#define freopen64 freopen
#define putchar(x) putc((x), stdout)
#define ftello64 ftello
#define _NO_FDISK_PRESENT
#define _BIT_FIELDS_HTOL
#define _LONG_LONG_ALIGNMENT 8
etcetera etcetera etcetera
A clue, no?
Josh Gerwin, System Programmer/Analyst
joshua.a.gerwin@intel.com
Intel Corp.
NorthWest Engineering Computing
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: preprocessor/6084: cpp Segmentation Fault
@ 2002-05-21 13:34 neil
0 siblings, 0 replies; 20+ messages in thread
From: neil @ 2002-05-21 13:34 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, joshg, nobody, rnesius, tuan.nguyen
Synopsis: cpp Segmentation Fault
State-Changed-From-To: feedback->closed
State-Changed-By: neil
State-Changed-When: Tue May 21 13:34:26 2002
State-Changed-Why:
Fixed I believe.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6084
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: preprocessor/6084: cpp Segmentation Fault
@ 2002-05-21 13:33 neil
0 siblings, 0 replies; 20+ messages in thread
From: neil @ 2002-05-21 13:33 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, joshg, nobody, rnesius, tuan.nguyen
Synopsis: cpp Segmentation Fault
State-Changed-From-To: closed->feedback
State-Changed-By: neil
State-Changed-When: Tue May 21 13:33:19 2002
State-Changed-Why:
I think you'll find this is fixed in 3.1; Jakub found
a fixed something suspiciously similar.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6084
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: preprocessor/6084: cpp Segmentation Fault
@ 2002-04-17 23:52 neil
0 siblings, 0 replies; 20+ messages in thread
From: neil @ 2002-04-17 23:52 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, joshg, nobody, rnesius, tuan.nguyen
Synopsis: cpp Segmentation Fault
State-Changed-From-To: feedback->closed
State-Changed-By: neil
State-Changed-When: Wed Apr 17 23:52:55 2002
State-Changed-Why:
It appears quite likely that this bug is not due to CPP, but
a compiler or environment problem. If you manage to find
out any more about what is causing it, particularly if it's
CPP-related, I'll happily re-open this PR.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6084
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: preprocessor/6084: cpp Segmentation Fault
@ 2002-04-15 19:46 Gerwin, Joshua A
0 siblings, 0 replies; 20+ messages in thread
From: Gerwin, Joshua A @ 2002-04-15 19:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/6084; it has been noted by GNATS.
From: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
To: "'Richard Henderson'" <rth@redhat.com>
Cc: "'Neil Booth'" <neil@daikokuya.demon.co.uk>,
"'Phil Edwards'"<phil@jaj.com>, joshg@hf.intel.com, gcc-gnats@gcc.gnu.org,
rnesius@ichips.intel.com, "Nguyen, Tuan" <tuan.nguyen@intel.com>,
gcc-bugs@gcc.gnu.org
Subject: RE: preprocessor/6084: cpp Segmentation Fault
Date: Mon, 15 Apr 2002 19:38:17 -0700
> -----Original Message-----
> From: Richard Henderson [mailto:rth@redhat.com]
> Sent: Monday, April 15, 2002 6:06 PM
> To: Gerwin, Joshua A
> Cc: 'Neil Booth'; 'Phil Edwards'; joshg@hf.intel.com;
> gcc-gnats@gcc.gnu.org; rnesius@ichips.intel.com; Nguyen, Tuan;
> gcc-bugs@gcc.gnu.org
> Subject: Re: preprocessor/6084: cpp Segmentation Fault
>
>
> On Mon, Apr 15, 2002 at 11:25:25AM -0700, Gerwin, Joshua A wrote:
> > (gdb) break maybe_print_line
> > Cannot access memory at address 0x3c28
>
> You built the compiler as a 64-bit binary didn't you?
Clearly this is something not to be taken on lightly...Actually, a co-worker
built the compiler, it is 64-bit. I did build the debugger as 64-bit,
though.
>
> (1) 64-bit sparc code isn't stable in gcc 3.0,
Oops...
> (2) Use -mcmodel=medlow to link the application below 4GB so
> that stabs debugging can function properly.
>
Thanks. This could help quite a bit.
>
> r~
>
Josh Gerwin, System Programmer/Analyst
joshua.a.gerwin@intel.com
Intel Corp.
NorthWest Engineering Computing
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: preprocessor/6084: cpp Segmentation Fault
@ 2002-04-15 18:06 Richard Henderson
0 siblings, 0 replies; 20+ messages in thread
From: Richard Henderson @ 2002-04-15 18:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/6084; it has been noted by GNATS.
From: Richard Henderson <rth@redhat.com>
To: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
Cc: "'Neil Booth'" <neil@daikokuya.demon.co.uk>,
"'Phil Edwards'" <phil@jaj.com>, joshg@hf.intel.com, gcc-gnats@gcc.gnu.org,
rnesius@ichips.intel.com, "Nguyen, Tuan" <tuan.nguyen@intel.com>,
gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/6084: cpp Segmentation Fault
Date: Mon, 15 Apr 2002 18:05:36 -0700
On Mon, Apr 15, 2002 at 11:25:25AM -0700, Gerwin, Joshua A wrote:
> (gdb) break maybe_print_line
> Cannot access memory at address 0x3c28
You built the compiler as a 64-bit binary didn't you?
(1) 64-bit sparc code isn't stable in gcc 3.0,
(2) Use -mcmodel=medlow to link the application below 4GB so
that stabs debugging can function properly.
r~
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: preprocessor/6084: cpp Segmentation Fault
@ 2002-04-15 12:06 'Neil Booth'
0 siblings, 0 replies; 20+ messages in thread
From: 'Neil Booth' @ 2002-04-15 12:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/6084; it has been noted by GNATS.
From: 'Neil Booth' <neil@daikokuya.demon.co.uk>
To: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>, gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org
Cc:
Subject: Re: preprocessor/6084: cpp Segmentation Fault
Date: Mon, 15 Apr 2002 19:56:55 +0100
Gerwin, Joshua A wrote:-
> I would if I could, but the debugger often reports back that it can't get at
> the variables in question.
>
> (gdb) info mem
> Num Enb Low Addr High Addr Attrs
> 2 y 0x000000010000349c 0x0000000100012344 rw nocache
> 1 y 0x000000000011b018 0x0000000000120000 rw nocache
> (gdb) break maybe_print_line
> Cannot access memory at address 0x3c28
>
> for instance. This prohibition is applied to display, print, and trace as
> well. I've had some success in getting DDD to sneak in there, and I'll see
> if I can convince it can put a display on the print structure.
Does it occur if you compile cpp0 without optimization?
Neil.
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: preprocessor/6084: cpp Segmentation Fault
@ 2002-04-15 11:36 Gerwin, Joshua A
0 siblings, 0 replies; 20+ messages in thread
From: Gerwin, Joshua A @ 2002-04-15 11:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/6084; it has been noted by GNATS.
From: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
To: "'Neil Booth'" <neil@daikokuya.demon.co.uk>,
"Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
Cc: "'Phil Edwards'" <phil@jaj.com>, joshg@hf.intel.com, gcc-gnats@gcc.gnu.org,
rnesius@ichips.intel.com, "Nguyen, Tuan"<tuan.nguyen@intel.com>,
gcc-bugs@gcc.gnu.org
Subject: RE: preprocessor/6084: cpp Segmentation Fault
Date: Mon, 15 Apr 2002 11:25:25 -0700
> -----Original Message-----
> From: 'Neil Booth' [mailto:neil@daikokuya.demon.co.uk]
> Sent: Monday, April 15, 2002 11:16 AM
> To: Gerwin, Joshua A
> Cc: 'Phil Edwards'; joshg@hf.intel.com; gcc-gnats@gcc.gnu.org;
> rnesius@ichips.intel.com; Nguyen, Tuan; gcc-bugs@gcc.gnu.org
> Subject: Re: preprocessor/6084: cpp Segmentation Fault
>
>
> Gerwin, Joshua A wrote:-
>
> > OK, here's my theory as to why I think you aren't seeing it in
> > maybe_print_line. Often when we compile, we use an
> optimizing flag (admit
> > it, you do this sometimes too!) and in this case the
> optimizer dropped the
> > jump to the separate print_line function and put the
> fprintf directly in
> > maybe_print_line. So in cppmain.c (line 329 by my
> reckoning), effectively
> > substitute
> >
> > else
> > {
> > print.lineno = line;
> > print_line ("");
> > }
> >
> > with
> >
> > else
> > {
> > print.lineno = line;
> > if (print.printed) putc ('\n', print.outf);
> > print.printed = 0;
> > fprintf (print.outf, "# %u \"%s\"%s%s\n",
> > print.lineno, print.last_fname, "", print.syshdr_flags);
> > }
> >
> > This saves a subroutine call.
>
> OK. Why can't you give me more info? Like the variables in question;
> clearly one is NULL? Maybe investigate why it is NULL in this case
> and not when you switch command line args? It would save us
> both a lot
> of time.
>
> Neil.
>
I would if I could, but the debugger often reports back that it can't get at
the variables in question.
(gdb) info mem
Num Enb Low Addr High Addr Attrs
2 y 0x000000010000349c 0x0000000100012344 rw nocache
1 y 0x000000000011b018 0x0000000000120000 rw nocache
(gdb) break maybe_print_line
Cannot access memory at address 0x3c28
for instance. This prohibition is applied to display, print, and trace as
well. I've had some success in getting DDD to sneak in there, and I'll see
if I can convince it can put a display on the print structure.
-- Josh
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: preprocessor/6084: cpp Segmentation Fault
@ 2002-04-15 11:16 'Neil Booth'
0 siblings, 0 replies; 20+ messages in thread
From: 'Neil Booth' @ 2002-04-15 11:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/6084; it has been noted by GNATS.
From: 'Neil Booth' <neil@daikokuya.demon.co.uk>
To: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
Cc: 'Phil Edwards' <phil@jaj.com>, joshg@hf.intel.com,
gcc-gnats@gcc.gnu.org, rnesius@ichips.intel.com,
"Nguyen, Tuan" <tuan.nguyen@intel.com>, gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/6084: cpp Segmentation Fault
Date: Mon, 15 Apr 2002 19:15:40 +0100
Gerwin, Joshua A wrote:-
> OK, here's my theory as to why I think you aren't seeing it in
> maybe_print_line. Often when we compile, we use an optimizing flag (admit
> it, you do this sometimes too!) and in this case the optimizer dropped the
> jump to the separate print_line function and put the fprintf directly in
> maybe_print_line. So in cppmain.c (line 329 by my reckoning), effectively
> substitute
>
> else
> {
> print.lineno = line;
> print_line ("");
> }
>
> with
>
> else
> {
> print.lineno = line;
> if (print.printed) putc ('\n', print.outf);
> print.printed = 0;
> fprintf (print.outf, "# %u \"%s\"%s%s\n",
> print.lineno, print.last_fname, "", print.syshdr_flags);
> }
>
> This saves a subroutine call.
OK. Why can't you give me more info? Like the variables in question;
clearly one is NULL? Maybe investigate why it is NULL in this case
and not when you switch command line args? It would save us both a lot
of time.
Neil.
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: preprocessor/6084: cpp Segmentation Fault
@ 2002-04-15 11:06 Gerwin, Joshua A
0 siblings, 0 replies; 20+ messages in thread
From: Gerwin, Joshua A @ 2002-04-15 11:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/6084; it has been noted by GNATS.
From: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
To: "'Neil Booth'" <neil@daikokuya.demon.co.uk>,
"Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
Cc: "'Phil Edwards'" <phil@jaj.com>, joshg@hf.intel.com, gcc-gnats@gcc.gnu.org,
rnesius@ichips.intel.com, "Nguyen, Tuan"<tuan.nguyen@intel.com>,
gcc-bugs@gcc.gnu.org
Subject: RE: preprocessor/6084: cpp Segmentation Fault
Date: Mon, 15 Apr 2002 11:02:43 -0700
> -----Original Message-----
> From: Neil Booth [mailto:neil@daikokuya.demon.co.uk]
> Sent: Friday, April 12, 2002 10:07 PM
> To: Gerwin, Joshua A
> Cc: 'Phil Edwards'; joshg@hf.intel.com; gcc-gnats@gcc.gnu.org;
> rnesius@ichips.intel.com; Nguyen, Tuan; gcc-bugs@gcc.gnu.org
> Subject: Re: preprocessor/6084: cpp Segmentation Fault
>
>
> Gerwin, Joshua A wrote:-
>
> > #1 0xffffffff7f48d6d4 in _doprnt () from /usr/lib/64/libc.so.1
> > #2 0xffffffff7f48f180 in fprintf () from /usr/lib/64/libc.so.1
> > #3 0x100003d28 in maybe_print_line ()
> > #4 0x100003e1c in cb_define ()
> > #5 0x100004904 in do_define ()
> > #6 0x100004778 in run_directive ()
> > #7 0x100011d20 in init_builtins ()
> > #8 0x100012344 in cpp_start_read ()
> > #9 0x100003680 in do_preprocessing ()
> > #10 0x10000349c in main ()
>
> As I've already pointed out to you, and you confirmed with your
> mail, there is no fprintf() in the function maybe_print_line.
>
OK, here's my theory as to why I think you aren't seeing it in
maybe_print_line. Often when we compile, we use an optimizing flag (admit
it, you do this sometimes too!) and in this case the optimizer dropped the
jump to the separate print_line function and put the fprintf directly in
maybe_print_line. So in cppmain.c (line 329 by my reckoning), effectively
substitute
else
{
print.lineno = line;
print_line ("");
}
with
else
{
print.lineno = line;
if (print.printed) putc ('\n', print.outf);
print.printed = 0;
fprintf (print.outf, "# %u \"%s\"%s%s\n",
print.lineno, print.last_fname, "", print.syshdr_flags);
}
This saves a subroutine call.
> > Also noteworthy, reversing the parameters fixes the segfault!
>
> That makes me even more suspicious that something is very wrong
> with your env. Exactly the same code should be running, with the
> same internal state, once you get to do_preprocessing()
> when you flip the order.
Right. I wouldn't be a bit surprised if something is very wrong with this
platform environment. I've been doing compiles on Solaris 5.8 that work
flawlessly, when they break down on Solaris 2.7 for what appears to be No
Good Reason.
>
> Phil, could I ask you to try what Joshua claims above on 3.0 branch,
> if you still have it lying around? If you still can't get anything,
> I'll close this PR, since it is unreproducable with a seemingly
> impossible backtrace.
>
> Thanks a lot,
>
> Neil.
>
While I respectfully disagree that it's completely impossible, and it is
reproducable on at least this particular platform, I will not overly object
to closing out the PR as it may be specific to some peculiarity of our
compiler and/or OS environment. If you think of anything else worth
checking, let me know.
Thanks for your assistance.
Josh Gerwin, System Programmer/Analyst
joshua.a.gerwin@intel.com
Intel Corp.
NorthWest Engineering Computing
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: preprocessor/6084: cpp Segmentation Fault
@ 2002-04-13 1:26 Phil Edwards
0 siblings, 0 replies; 20+ messages in thread
From: Phil Edwards @ 2002-04-13 1:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/6084; it has been noted by GNATS.
From: Phil Edwards <phil@jaj.com>
To: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
Cc: joshg@hf.intel.com, gcc-gnats@gcc.gnu.org, rnesius@ichips.intel.com,
"Nguyen, Tuan" <tuan.nguyen@intel.com>, gcc-bugs@gcc.gnu.org,
neil@daikokuya.demon.co.uk
Subject: Re: preprocessor/6084: cpp Segmentation Fault
Date: Sat, 13 Apr 2002 04:20:53 -0400
On Fri, Apr 12, 2002 at 03:57:12PM -0700, Gerwin, Joshua A wrote:
> My hunch is that this is either a 3.0 problem, perhaps fixed in your version
> of 3.1, or that the libc.so we're linking during compile is significantly
> different.
During compile of...? The compiler itself? If your libc.so were that
broken, I'd expect much bigger breakage much earlier.
> Program received signal SIGSEGV, Segmentation fault.
> 0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
> (gdb) bt
> #0 0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
> #1 0xffffffff7f48d6d4 in _doprnt () from /usr/lib/64/libc.so.1
> #2 0xffffffff7f48f180 in fprintf () from /usr/lib/64/libc.so.1
Something is very weird here. I don't recall a "/usr/lib/64" directory under
SPARC/Solaris 7. The 64-bit version should be /usr/lib/sparcv9/libc.so.1.
Phil
--
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace. We seek
not your counsel, nor your arms. Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen. - Samuel Adams
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: preprocessor/6084: cpp Segmentation Fault
@ 2002-04-13 1:16 Phil Edwards
0 siblings, 0 replies; 20+ messages in thread
From: Phil Edwards @ 2002-04-13 1:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/6084; it has been noted by GNATS.
From: Phil Edwards <phil@jaj.com>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>, joshg@hf.intel.com,
gcc-gnats@gcc.gnu.org, rnesius@ichips.intel.com,
"Nguyen, Tuan" <tuan.nguyen@intel.com>, gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/6084: cpp Segmentation Fault
Date: Sat, 13 Apr 2002 04:15:28 -0400
On Sat, Apr 13, 2002 at 06:07:26AM +0100, Neil Booth wrote:
> Phil, could I ask you to try what Joshua claims above on 3.0 branch,
> if you still have it lying around?
I do (3.0.2), but all the machines are tied up for the next day and a half.
Will test then.
Phil
--
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace. We seek
not your counsel, nor your arms. Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen. - Samuel Adams
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: preprocessor/6084: cpp Segmentation Fault
@ 2002-04-12 22:16 Neil Booth
0 siblings, 0 replies; 20+ messages in thread
From: Neil Booth @ 2002-04-12 22:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/6084; it has been noted by GNATS.
From: Neil Booth <neil@daikokuya.demon.co.uk>
To: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
Cc: 'Phil Edwards' <phil@jaj.com>, joshg@hf.intel.com,
gcc-gnats@gcc.gnu.org, rnesius@ichips.intel.com,
"Nguyen, Tuan" <tuan.nguyen@intel.com>, gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/6084: cpp Segmentation Fault
Date: Sat, 13 Apr 2002 06:07:26 +0100
Gerwin, Joshua A wrote:-
> #1 0xffffffff7f48d6d4 in _doprnt () from /usr/lib/64/libc.so.1
> #2 0xffffffff7f48f180 in fprintf () from /usr/lib/64/libc.so.1
> #3 0x100003d28 in maybe_print_line ()
> #4 0x100003e1c in cb_define ()
> #5 0x100004904 in do_define ()
> #6 0x100004778 in run_directive ()
> #7 0x100011d20 in init_builtins ()
> #8 0x100012344 in cpp_start_read ()
> #9 0x100003680 in do_preprocessing ()
> #10 0x10000349c in main ()
As I've already pointed out to you, and you confirmed with your
mail, there is no fprintf() in the function maybe_print_line.
> Also noteworthy, reversing the parameters fixes the segfault!
That makes me even more suspicious that something is very wrong
with your env. Exactly the same code should be running, with the
same internal state, once you get to do_preprocessing()
when you flip the order.
> Here's the maybe_print_line function and related symbols, for handy
> reference:
I have the source on my machine, and the types, so this doesn't help.
What does help is you backing up the call stack and finding out why
the segfault is happening (and the offending variable at the time).
Phil, could I ask you to try what Joshua claims above on 3.0 branch,
if you still have it lying around? If you still can't get anything,
I'll close this PR, since it is unreproducable with a seemingly
impossible backtrace.
Thanks a lot,
Neil.
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: preprocessor/6084: cpp Segmentation Fault
@ 2002-04-12 16:06 Gerwin, Joshua A
0 siblings, 0 replies; 20+ messages in thread
From: Gerwin, Joshua A @ 2002-04-12 16:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/6084; it has been noted by GNATS.
From: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
To: "'Phil Edwards'" <phil@jaj.com>, joshg@hf.intel.com, gcc-gnats@gcc.gnu.org,
rnesius@ichips.intel.com, "Nguyen, Tuan"<tuan.nguyen@intel.com>,
gcc-bugs@gcc.gnu.org, neil@daikokuya.demon.co.uk
Cc:
Subject: RE: preprocessor/6084: cpp Segmentation Fault
Date: Fri, 12 Apr 2002 15:57:12 -0700
> -----Original Message-----
> From: Phil Edwards [mailto:phil@jaj.com]
> Sent: Friday, April 12, 2002 1:27 PM
> To: joshg@hf.intel.com; gcc-gnats@gcc.gnu.org;
> rnesius@ichips.intel.com;
> tuan.nguyen@intel.com; gcc-bugs@gcc.gnu.org;
> neil@daikokuya.demon.co.uk
> Subject: Re: preprocessor/6084: cpp Segmentation Fault
>
>
> I haven't been able to reproduce this using today's 3.1
> sources. (More at
> the end.)
>
My hunch is that this is either a 3.0 problem, perhaps fixed in your version
of 3.1, or that the libc.so we're linking during compile is significantly
different. Note that I could produce a segfault in strlen with minimal
options and no source at all, simply by having both -dD and -DM present.
%cat empty.c
/* no source */
%which cpp
/path/to/gcc/3.0.3-64/bin/cpp
%cpp -dM -dD empty.c
cpp: Internal error: Segmentation Fault (program cpp0)
Please submit a full bug report.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
Running gcc, I observe
(gdb) file /path/to/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0
Load new symbol table from
"/path/to/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0"? (y or
n) y
Reading symbols from
/path/to/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0...done.
(gdb) run -dM -dD empty.c
Starting program:
/path/to/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0 -dM -dD
empty.c
Program received signal SIGSEGV, Segmentation fault.
0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
(gdb) bt
#0 0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
#1 0xffffffff7f48d6d4 in _doprnt () from /usr/lib/64/libc.so.1
#2 0xffffffff7f48f180 in fprintf () from /usr/lib/64/libc.so.1
#3 0x100003d28 in maybe_print_line ()
#4 0x100003e1c in cb_define ()
#5 0x100004904 in do_define ()
#6 0x100004778 in run_directive ()
#7 0x100011d20 in init_builtins ()
#8 0x100012344 in cpp_start_read ()
#9 0x100003680 in do_preprocessing ()
#10 0x10000349c in main ()
(gdb)
Also noteworthy, reversing the parameters fixes the segfault!
(gdb) run -dD -dM
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program:
/usr/intel/pkgs/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0 -dD
-dM
^D
#define __USER_LABEL_PREFIX__
#define __HAVE_BUILTIN_SETJMP__ 1
#define __REGISTER_PREFIX__
#define __VERSION__ "3.0.3"
Program exited normally.
(gdb) run -dM -dD
Starting program:
/usr/intel/pkgs/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0 -dM
-dD
^D
Program received signal SIGSEGV, Segmentation fault.
0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
Here's the maybe_print_line function and related symbols, for handy
reference:
static void
maybe_print_line (line)
unsigned int line;
{
/* End the previous line of text (probably only needed until we get
multi-line tokens fixed). */
if (print.printed)
{
putc ('\n', print.outf);
print.lineno++;
print.printed = 0;
}
if (options->no_line_commands)
{
print.lineno = line;
return;
}
/* print.lineno is zero if this is the first token of the file. We
handle this specially, so that a first line of "# 1 "foo.c" in
file foo.i outputs just the foo.c line, and not a foo.i line. */
if (line >= print.lineno && line < print.lineno + 8 && print.lineno)
{
while (line > print.lineno)
{
putc ('\n', print.outf);
print.lineno++;
}
}
else
{
print.lineno = line;
print_line ("");
}
}
static void
print_line (special_flags)
const char *special_flags;
{
/* End any previous line of text. */
if (print.printed)
putc ('\n', print.outf);
print.printed = 0;
fprintf (print.outf, "# %u \"%s\"%s%s\n",
print.lineno, print.last_fname, special_flags,
print.syshdr_flags);
}
(gdb) whatis print
type = struct printer
(gdb) ptype struct printer
type = struct printer {
FILE *outf;
char *last_fname;
char *syshdr_flags;
unsigned int lineno;
unsigned char printed;
}
This is about all the source diving I can do for it today.
Josh Gerwin, System Programmer/Analyst
joshua.a.gerwin@intel.com
Intel Corp.
NorthWest Engineering Computing
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: preprocessor/6084: cpp Segmentation Fault
@ 2002-04-12 13:36 Phil Edwards
0 siblings, 0 replies; 20+ messages in thread
From: Phil Edwards @ 2002-04-12 13:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/6084; it has been noted by GNATS.
From: Phil Edwards <phil@jaj.com>
To: joshg@hf.intel.com, gcc-gnats@gcc.gnu.org, rnesius@ichips.intel.com,
tuan.nguyen@intel.com, gcc-bugs@gcc.gnu.org, neil@daikokuya.demon.co.uk
Cc:
Subject: Re: preprocessor/6084: cpp Segmentation Fault
Date: Fri, 12 Apr 2002 16:27:07 -0400
I haven't been able to reproduce this using today's 3.1 sources. (More at
the end.)
55% cat 6084_hello.c
#include <stdio.h>
#ifdef MATHTEST
#include <math.h>
#endif
main()
{
float X;
printf("Hello, World! \n");
#ifdef MATHTEST
X = sqrt(4);
printf("the sqrt of 4 is %f \n", X);
#endif
}
56% gcc -DPERL_CORE -fno-strict-aliasing -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -mcpu=v9 -m64 -Wa,-xarch=v9 -O3 -m64 -dM -dD -dI -v 6084_hello.c
Reading specs from /local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/specs
Configured with: /local/pme/unified/configure --prefix=/local/pme/instdir-v9 --enable-languages=c sparcv9-sun-solaris2.8
Thread model: posix
gcc version 3.1 20020412 (prerelease)
/local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -D__SIZE_TYPE__=long unsigned int -D__PTRDIFF_TYPE__=long int -D__WCHAR_TYPE__=int -D__WINT_TYPE__=int -D__arch64__ -Acpu=sparc64 -Amachin e=sparcv9 -D__sparcv9 -DPERL_CORE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 6084_hello.c -quiet -dumpbase 6084_hello.c -dM -dD -dI -mcpu=v9 -m64 -m64 -O3 -version -fno-strict-aliasing -o /tmp/pedwards/ccGyKzGh.s
GNU CPP version 3.1 20020412 (prerelease) (cpplib) (sparc ELF)
GNU C version 3.1 20020412 (prerelease) (sparcv9-sun-solaris2.8)
compiled by GNU C version 3.1 20020412 (prerelease).
ignoring nonexistent directory "/local/pme/instdir-v9/sparcv9-sun-solaris2.8/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/local/pme/instdir-v9/include
/local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/include
/usr/include
End of search list.
/usr/ccs/bin/as -V -Qy -s -xarch=v9 -xarch=v9 -o /tmp/pedwards/ccLEQgFp.o /tmp/pedwards/ccGyKzGh.s
/usr/ccs/bin/as: Sun WorkShop 6 99/08/18
/local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/collect2 -V -Y P,/usr/lib/sparcv9 -Qy /local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/crt1.o /local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/crti.o /usr/lib/sparcv9/values-Xa.o /local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/crtbegin.o -L/local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1 -L/usr/ccs/bin -L/usr/ccs/lib -L/local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/../../.. /tmp/pedw ards/ccLEQgFp.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -lc /local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/crtend.o /local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/crtn.o
ld: Software Generation Utilities - Solaris-ELF (4.0)
57%
A few observations that probably make no difference to this PR:
- I note that you configured your compiler for "sparcv9-sun-solaris2".
Usually the final bit is a complete OS version, like 2.7 or 2.8.
- Your system was reported as
SunOS 5.7 Generic_106541-19 sun4u sparc SUNW,Ultra-2
The one I used to test is
SunOS 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-30
- You mentioned you were using NFS and AFS. My test was all local.
Phil
--
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace. We seek
not your counsel, nor your arms. Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen. - Samuel Adams
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: preprocessor/6084: cpp Segmentation Fault
@ 2002-04-03 22:36 'Neil Booth'
0 siblings, 0 replies; 20+ messages in thread
From: 'Neil Booth' @ 2002-04-03 22:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/6084; it has been noted by GNATS.
From: 'Neil Booth' <neil@daikokuya.demon.co.uk>
To: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
Cc: "'neil@gcc.gnu.org'" <neil@gcc.gnu.org>,
"'gcc-bugs@gcc.gnu.org'" <gcc-bugs@gcc.gnu.org>,
"'joshg@hf.intel.com'" <joshg@hf.intel.com>,
"'rnesius@ichips.intel.com'" <rnesius@ichips.intel.com>,
"Nguyen, Tuan" <tuan.nguyen@intel.com>,
"'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>
Subject: Re: preprocessor/6084: cpp Segmentation Fault
Date: Thu, 4 Apr 2002 07:27:00 +0100
Gerwin, Joshua A wrote:-
> (gdb) run -dM -dD ../accessories/hello.c
> Starting program:
> /(path/to)/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0 -dM -dD
> ../accessories/hello.c
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
> (gdb) bt
> #0 0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
> #1 0xffffffff7f48d6d4 in _doprnt () from /usr/lib/64/libc.so.1
> #2 0xffffffff7f48f180 in fprintf () from /usr/lib/64/libc.so.1
> #3 0x100003d28 in maybe_print_line ()
> #4 0x100003e1c in cb_define ()
> #5 0x100004904 in do_define ()
> #6 0x100004778 in run_directive ()
> #7 0x100011d20 in init_builtins ()
> #8 0x100012344 in cpp_start_read ()
> #9 0x100003680 in do_preprocessing ()
> #10 0x10000349c in main ()
That's curious, because there is no fprintf in my version of 3.0.3
in maybe_print_line. Have you patched yours from stock 3.0.3?
Could you do some more research - I have no clue from the above
backtrace. Maybe step in yourself and see what's going wrong?
Neil.
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: preprocessor/6084: cpp Segmentation Fault
@ 2002-04-03 17:06 Gerwin, Joshua A
0 siblings, 0 replies; 20+ messages in thread
From: Gerwin, Joshua A @ 2002-04-03 17:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/6084; it has been noted by GNATS.
From: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
To: "'Neil Booth'" <neil@daikokuya.demon.co.uk>
Cc: "'neil@gcc.gnu.org'" <neil@gcc.gnu.org>,
"'gcc-bugs@gcc.gnu.org'"<gcc-bugs@gcc.gnu.org>,
"'joshg@hf.intel.com'" <joshg@hf.intel.com>,
"'rnesius@ichips.intel.com'" <rnesius@ichips.intel.com>,
"Nguyen, Tuan"<tuan.nguyen@intel.com>,
"'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>
Subject: RE: preprocessor/6084: cpp Segmentation Fault
Date: Wed, 3 Apr 2002 16:57:40 -0800
I bit the bullet, built gdb on the 64-bit solaris 2.7 platform, and here's
what I see:
(gdb) run -dM -dD ../accessories/hello.c
Starting program:
/(path/to)/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0 -dM -dD
../accessories/hello.c
Program received signal SIGSEGV, Segmentation fault.
0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
(gdb) bt
#0 0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
#1 0xffffffff7f48d6d4 in _doprnt () from /usr/lib/64/libc.so.1
#2 0xffffffff7f48f180 in fprintf () from /usr/lib/64/libc.so.1
#3 0x100003d28 in maybe_print_line ()
#4 0x100003e1c in cb_define ()
#5 0x100004904 in do_define ()
#6 0x100004778 in run_directive ()
#7 0x100011d20 in init_builtins ()
#8 0x100012344 in cpp_start_read ()
#9 0x100003680 in do_preprocessing ()
#10 0x10000349c in main ()
(gdb)
> -----Original Message-----
> From: Neil Booth [mailto:neil@daikokuya.demon.co.uk]
> Sent: Tuesday, April 02, 2002 10:26 PM
> To: Gerwin, Joshua A
> Cc: 'neil@gcc.gnu.org'; 'gcc-bugs@gcc.gnu.org'; 'joshg@hf.intel.com';
> 'rnesius@ichips.intel.com'; Nguyen, Tuan; 'gcc-gnats@gcc.gnu.org'
> Subject: Re: preprocessor/6084: cpp Segmentation Fault
>
>
> So, do you have a backtrace? All you need to do is run the program
> cpp0 within GDB, with the command line arguments you gave, and
> when it segfaults give the "bt" command.
>
> Neil.
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: preprocessor/6084: cpp Segmentation Fault
@ 2002-04-02 22:36 Neil Booth
0 siblings, 0 replies; 20+ messages in thread
From: Neil Booth @ 2002-04-02 22:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/6084; it has been noted by GNATS.
From: Neil Booth <neil@daikokuya.demon.co.uk>
To: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
Cc: "'neil@gcc.gnu.org'" <neil@gcc.gnu.org>,
"'gcc-bugs@gcc.gnu.org'" <gcc-bugs@gcc.gnu.org>,
"'joshg@hf.intel.com'" <joshg@hf.intel.com>,
"'rnesius@ichips.intel.com'" <rnesius@ichips.intel.com>,
"Nguyen, Tuan" <tuan.nguyen@intel.com>,
"'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>
Subject: Re: preprocessor/6084: cpp Segmentation Fault
Date: Wed, 3 Apr 2002 07:26:29 +0100
So, do you have a backtrace? All you need to do is run the program
cpp0 within GDB, with the command line arguments you gave, and
when it segfaults give the "bt" command.
Neil.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: preprocessor/6084: cpp Segmentation Fault
@ 2002-03-29 12:16 Neil Booth
0 siblings, 0 replies; 20+ messages in thread
From: Neil Booth @ 2002-03-29 12:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/6084; it has been noted by GNATS.
From: Neil Booth <neil@daikokuya.demon.co.uk>
To: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
Cc: "'neil@gcc.gnu.org'" <neil@gcc.gnu.org>,
"'gcc-bugs@gcc.gnu.org'" <gcc-bugs@gcc.gnu.org>,
"'gcc-prs@gcc.gnu.org'" <gcc-prs@gcc.gnu.org>,
"'joshg@hf.intel.com'" <joshg@hf.intel.com>,
"'nobody@gcc.gnu.org'" <nobody@gcc.gnu.org>,
"'rnesius@ichips.intel.com'" <rnesius@ichips.intel.com>,
"Nguyen, Tuan" <tuan.nguyen@intel.com>,
"'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>
Subject: Re: preprocessor/6084: cpp Segmentation Fault
Date: Fri, 29 Mar 2002 20:06:38 +0000
Gerwin, Joshua A wrote:-
> A minor experiment in option removal shows that the problem is potentially
> tied to the
> -dD tag. Compare:
>
[...]
>
> A clue, no?
A clue, but not much more. Sadly I can't reproduce the issue on x86
Linux.
Would you mind running it through gdb, and giving a backtrace of the
line it segfaults on, and any relevant-looking variables?
Thanks,
Neil.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: preprocessor/6084: cpp Segmentation Fault
@ 2002-03-29 0:20 neil
0 siblings, 0 replies; 20+ messages in thread
From: neil @ 2002-03-29 0:20 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, joshg, nobody, rnesius, tuan.nguyen
Synopsis: cpp Segmentation Fault
State-Changed-From-To: open->feedback
State-Changed-By: neil
State-Changed-When: Fri Mar 29 00:20:22 2002
State-Changed-Why:
Changed to category preprocessor; not a front end issue.
Quite a surpise to me, too. I take pride in cpp not segfaulting 8-)
Could you give me a testcase? I can't reproduce it with
the information supplied.
Or, could you try 3.0.4? There was a segfault fixed in the
later 3.0 cycle, triggered by a combination of command
line options, but I'm not sure which 3.0.x got it.
Judging by your command line, I suspect it is caused by
a certain combination of switches; can you reproduce it
on a simple file like #include <stdio.h> or something?
Alternatively, if you can't produce a simple testcase, but can get it to happen on Linux, then please send me the files so I can track this down, or tell me where it happens when you're debugging the cpp0 binary.
Thanks!
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6084
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2002-05-21 20:34 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-29 11:36 preprocessor/6084: cpp Segmentation Fault Gerwin, Joshua A
-- strict thread matches above, loose matches on Subject: below --
2002-05-21 13:34 neil
2002-05-21 13:33 neil
2002-04-17 23:52 neil
2002-04-15 19:46 Gerwin, Joshua A
2002-04-15 18:06 Richard Henderson
2002-04-15 12:06 'Neil Booth'
2002-04-15 11:36 Gerwin, Joshua A
2002-04-15 11:16 'Neil Booth'
2002-04-15 11:06 Gerwin, Joshua A
2002-04-13 1:26 Phil Edwards
2002-04-13 1:16 Phil Edwards
2002-04-12 22:16 Neil Booth
2002-04-12 16:06 Gerwin, Joshua A
2002-04-12 13:36 Phil Edwards
2002-04-03 22:36 'Neil Booth'
2002-04-03 17:06 Gerwin, Joshua A
2002-04-02 22:36 Neil Booth
2002-03-29 12:16 Neil Booth
2002-03-29 0:20 neil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).