public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "karsten_burger at gmx dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/13757] -fstack-check causes segfaults
Date: Wed, 04 Aug 2004 11:36:00 -0000 [thread overview]
Message-ID: <20040804113613.31953.qmail@sourceware.org> (raw)
In-Reply-To: <20040120042951.13757.duncan_roe@acslink.net.au>
------- Additional Comments From karsten_burger at gmx dot de 2004-08-04 11:35 -------
I would not like the "-fstack-check" to be removed from the compiler - it is needed to
debug multi-threaded applications. Found the bug on Mandrake 9.1 with gcc 3.2.2, too.
(In reply to comment #0)
> The -fstack-check compiler option emits code which can make any program
> segfault on entering its mainline.
> The placement of the stack relative to page boundaries needs to be right
> to demonstrate the problem.
> This placement varies with environment, length of pathname used to invoke the
> program, whether it is invoked directly or via GDB,
> and quite possibly other factors also.
> This is an old problem, I first saw it at gcc 2.95.3.
> Shell/expect scripts in How-To-Repeat demonstrate the problem reliably.
>
> This is a dissasem of main() :-
>
> 0x8048354 <main>: push %ebp
> 0x8048355 <main+1>: mov %esp,%ebp
> 0x8048357 <main+3>: sub $0x18,%esp
> 0x804835a <main+6>: and $0xfffffff0,%esp
> 0x804835d <main+9>: movl $0x0,0xfffffffc(%ebp)
> 0x8048364 <main+16>: lea 0xffffded8(%esp,1),%eax
> 0x804836b <main+23>: mov %eax,0xfffffff8(%ebp)
> 0x804836e <main+26>: mov 0xfffffffc(%ebp),%eax
> 0x8048371 <main+29>: add $0x1128,%eax
> 0x8048376 <main+34>: mov %esp,%edx
> 0x8048378 <main+36>: sub %eax,%edx
> 0x804837a <main+38>: mov %edx,0xfffffff4(%ebp)
> 0x804837d <main+41>: jmp 0x804838f <main+59>
> 0x804837f <main+43>: mov 0xfffffff8(%ebp),%eax
> 0x8048382 <main+46>: movl $0x0,(%eax)
> 0x8048388 <main+52>: subl $0x1000,0xfffffff8(%ebp)
> 0x804838f <main+59>: mov 0xfffffff4(%ebp),%edx
> 0x8048392 <main+62>: cmp %edx,0xfffffff8(%ebp)
> 0x8048395 <main+65>: ja 0x804837f <main+43>
> 0x8048397 <main+67>: mov 0xfffffff4(%ebp),%eax
> 0x804839a <main+70>: movl $0x0,(%eax)
> 0x80483a0 <main+76>: sub 0xfffffffc(%ebp),%esp
> 0x80483a3 <main+79>: lea 0xffffeed8(%esp,1),%eax
> 0x80483aa <main+86>: movl $0x0,(%eax)
> 0x80483b0 <main+92>: movl $0x8048424,(%esp,1)
> 0x80483b7 <main+99>: call 0x8048278 <printf>
> 0x80483bc <main+104>: mov $0x0,%eax
> 0x80483c1 <main+109>: leave
> 0x80483c2 <main+110>: ret
>
> The segfault occurs at 0x804839a <main+70>: movl $0x0,(%eax)
>
> Environment:
> System: Linux dimstar 2.4.24 #1 Sat Jan 10 17:03:52 EST 2004 i686 unknown
> Architecture: i686
>
>
> host: i686-pc-linux-gnu
> build: i686-pc-linux-gnu
> target: i686-pc-linux-gnu
> configured with: /usr/src/gcc-3.3.2/configure --prefix=/usr/local/gcc3.2
>
> How-To-Repeat:
> The preprocessed source:-
>
> ---------------------------- START hello.i ----------------------------
> extern int printf (__const char *__restrict __format, ...) ;
> int main(int argc,char**argv)
> {
> printf("\nHello World!\n\n");
> return 0 ;
> }
> ---------------------------- END hello.i ----------------------------
>
> This test script will verify that we get the crash.
> It works by increasing the length of the pathname of hello
> in 16 byte increnents until it crashes (copious output) :-
>
> ---------------------------- START sh.sh ----------------------------
> #!/bin/sh
> gcc -g -Wall -fstack-check -o hello hello.i
> i=aaaaaaaaaaaaaaa
> j=`/bin/pwd`
> while(true);do
> $j/hello || break
> j=$j/$i
> mkdir -p $j
> cp hello $j
> done
> echo "Failing path is $j"
> ---------------------------- END sh.sh ----------------------------
>
> This script discovers the required pathname to see the problem under gdb.
> It saves this in the command file "cmd" for future use :-
>
> ---------------------------- START demo.sh ----------------------------
> #!/bin/sh
> # expect treats all the shell lines as comment comtinuations \
> gcc -g -Wall -fstack-check -o hello hello.i; \
> i=aaaaaaaaaaaaaaa; \
> exec expect -f "$0" -- $i `/bin/pwd`
>
> # We need to find a path that shows the problem when run under gdb
>
> set i [lindex $argv 0]
> set j [lindex $argv 1]
>
> puts "Finding a pathname that displays the problem."
> puts "This may take a while..."
> log_user 0
>
> spawn sh
> expect "$ "
> set k 0
> set l 0
> while {1} \
> {
> puts -nonewline "$l\r"
> flush stdout
> set l [incr l]
> exp_send "gdb $j/hello\r"
> expect "(gdb) "
> exp_send "run\r"
> expect \
> {
> signal \
> {
> set k 1
> expect "(gdb) "
> exp_send "q\r"
> expect "(y or n) "
> exp_send "y\r"
> }
> normally \
> {
> expect "(gdb) "
> exp_send "q\r"
> }
> }
> expect "$ "
> if {$k} break
> set j $j/$i
> exec mkdir -p $j
> exec cp hello $j
> }
> puts "\nFailing path is $j"
> exec echo "gdb $j/hello" > cmd
> exec chmod a+x cmd
> puts "gdb invocation command stored in ./cmd"
> ---------------------------- END demo.sh ----------------------------
>
> After running demo.sh, you can invoke gdb by running cmd directly.
> Alternatively, you can run the following script to get directly to
> the first machine instruction in main() :-
>
> ---------------------------- START run_gdb.sh ----------------------------
> #!/bin/sh
> # expect treats all the shell lines as comment comtinuations \
> exec expect -f "$0"
> spawn ./cmd
> expect "(gdb) "
> exp_send "b __libc_start_main\r"
> expect "(gdb) "
> exp_send "run\r"
> expect "(gdb) "
> exp_send "n 11\r"
> expect "(gdb) "
> exp_send "si 10\r"
> expect "(gdb) "
> puts "\n\nYou can now interact with gdb."
> puts "If it won't exit for you (lost LWP or whatever), type \"////\" to kill it"
> exp_send " \r"
> interact //// exit
> ---------------------------- END run_gdb.sh ----------------------------
>
> At gcc3.2.2, you can use "si 17" to get to the actual failing instruction.
> At that point if you note the contents of eax and use "x" to examine that
> location, the program will continue without failing.
>
> Otherwise, 'movl $0x0,(%eax)' will fail.
> I do not understand why this should be.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13757
prev parent reply other threads:[~2004-08-04 11:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-20 4:30 [Bug c/13757] New: -fstack-check can crash Hello World gcc-bugzilla at gcc dot gnu dot org
2004-01-20 4:38 ` [Bug c/13757] " pinskia at gcc dot gnu dot org
2004-01-21 6:22 ` [Bug c/13757] -fstack-check causes segfaults dhazeghi at yahoo dot com
2004-08-04 11:36 ` karsten_burger at gmx dot de [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040804113613.31953.qmail@sourceware.org \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).