This looks suspiciously like the no-exec stack problem, see explanation
in the article below.
See also thread
http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00059.html
for a suggested workaround and an explanation of the involved problems
(otherwise I would have fixed that limitation long ago).
: Date: Thu, 6 Jan 2000 21:02:54 -0500 (EST)
: From: Steve Revilak <[EMAIL PROTECTED]>
: To: [EMAIL PROTECTED]
: Subject: BUG: gdb-4.17/4.18 - Solaris 2.6: Failure to call functions -- CAUSEFOUND
:
: Dear Sirs:
:
: This posting is made in followup to an earlier report dating 12/31/99
: (subject: BUG: gdb-4.17/4.18 - Solaris 2.6: Failure to call
: functions). In summary, the problem being experienced was that when
: any attempts were made to call functions from within the debugger, a
: segmentation fault would result.
:
: The cause of this was traced to a parameter (set-table at boot time) in
: Solaris 2.6. Under this revision of Solaris, one has the option to
: disable execution of code from within the stack -- the stack frames
: are marked as readable and writable; but not executable.
:
: The Solaris 2.6 Sysadmin Guide offers a few paragraphs in detail.
: (This is from page #894 of the printed manual, available as hypertext
: at the following URL:
:
:
:http://docs.sun.com:80/ab2/coll.47.4/SYSADMIN1/@Ab2PageView/idmatch(SECCONCEPTS-35)#SECCONCEPTS-35?Ab2Lang=C&Ab2Enc=iso-8859-1
:
: A number of security bugs are related to default executable stacks
: when their permissions are set to read, write and execute. While
: stacks with execute permissions set are mandated by the SPARC ABI
: and Intel ABI, most programs can function correctly without using
: executable stacks.
:
: The noexec_user_stack variable is available in the Solaris 2.6
: release which enables the system administrator to specify whether
: stack mappings are executable or not. By default, the variable is
: zero, which provides ABI-compliant behavior. If the variable is set
: to non-zero, the system will mark the stack of every process in the
: system as readable and writable, but not executable.
:
: Once this variable is set, programs that attempt to execute code on
: their stack will be sent a SIGSEGV signal, which usually results in
: the program terminating with a core dump. Such programs also
: generate a warning message that includes the name of the offending
: program, the process ID, and real UID of the user who ran the
: program.
:
:
: In addition, such attempts to call functions may be logged as shown in
: the following example:
:
: a.out[23579] attempt to execute code on stack by uid 9999
:
: Given this, it's easy to see what's happening. GDB tries to execute
: the function call on a stack frame; the stack frame has been marked as
: "non-executable" and "splat" -- one debugger on the wrong end of the
: fly-swatter.
:
: (Thanks extended to [EMAIL PROTECTED] for pointing me to this
: information).
:
: >From what I've been informed, the "security risks" at issue are buffer
: overruns; by disabling execution of code on the stack, the ability of
: a hacker to exploit this point of entry is greatly reduced. Thus,
: it's quite understandable *why* system administrators would wish to
: configure machines in this manner.
:
:
: The focus then turns to dealing with the issue. Under the description
: of "call" (pg# 108 of the printed gdb-4.17 manual, also viewable at
: the following URL:
:
: http://www.gnu.org/manual/gdb-4.17/html_chapter/gdb_12.html#SEC96
:
: there is a mention of a means to have code executed from memory
: locations *other* than the stack:
:
: A new user-controlled variable, call_scratch_address, specifies the
: location of a scratch area to be used when GDB calls a function in
: the target. This is necessary because the usual method of putting
: the scratch area on the stack does not work in systems that have
: separate instruction and data spaces.
:
: But no further mention of this is made in the gdb manual.
: (Unfortunate, because it would seem that such an option might solve
: the problem in this case).
:
: >From the distribution, "NEWS", "Changelog-92" and, "Changelog-93"
: mention call_scratch_address briefly, but only in conjunction with the
: AMD29K processor.
:
: Should the maintainers have suggestions for implementing a workaround,
: I would be happy to compile and test.
:
: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
: Steve Revilak
: [EMAIL PROTECTED]
> This is a follow-up to the bug report I filed a few days ago. I have
> fixed one of the bugs, but the second bug (the one which prevents
> calling functions from gdb) appears to be an interaction with Solaris
> 2.7 patches.
>
> We have a number of different Sun machines (Sparcs, Ultra-1s,
> Ultra-5s, 450s, 6500s, etc.), some running at different patch levels.
> The ones at patch level 106541-07 or below don't exhibit any problems
> with gdb-4.17 or gdb-4.18. However, the machines at patch level
> 106541-08 and 106541-09 exhibit the bug. To make matters more
> confusing, all versions of gdb work on another machine with patch
> level 106541-09, but that machine has lots of other patches not on any
> other machines.
>
> In any case, we are about to undertake the project of trying to figure
> out which Sun patches cause and/or fix the problem. Of course, Sun
> won't help because gdb is not a Sun product. And RedHat/Cygnus won't
> be able to help because they'd need to reproduce our patch-level
> environment to even generate the problem. Very frustrating.
>
> If anyone out there has the same problem that we do, please send me
> some e-mail and let me know what patch level your machine is running
> at. All of our problems are occurring on Ultras running 64-bit
> kernels.
>
> Thanks in advance,
> -- David Magerman
> [EMAIL PROTECTED]
>
> P.S. - Here is a brief summary of the bug:
>
> Given the program:
>
> foo.C:
> ---------
> int baz(int k) { return k; }
> int main() { int i = baz(15); return 0; }
>
> compiled using g++-2.95.2, I get the following behavior:
>
> bat:~> gdb-4.18 a.out
> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "sparc-sun-solaris2.7"...
> (gdb) break main
> Breakpoint 1 at 0x10568: file foo.C, line 2.
> (gdb) run
> Starting program: /home/magerman/a.out
>
> Breakpoint 1, main () at foo.C:2
> 2 int main() { int i = baz(15); return 0; }
> (gdb) print baz(20)
>
> Program received signal SIGSEGV, Segmentation fault.
> <function called from gdb>
> The program being debugged stopped while in a function called from GDB.
> When the function (baz(int)) is done executing, GDB will silently
> stop (instead of continuing to evaluate the expression containing
> the function call).
> (gdb) quit
> bat:~>
>
>
>
--
Peter Schauer [EMAIL PROTECTED]
