Is this a kernel problem? segmentation fault

Is this a kernel problem? segmentation fault

[Donald Harter]

     I started by debugging this program where I was getting a segmentation fault.  I used gdb and traced the bug to a call instruction.  I dissasembled the code and stepped through the instructions.  The program  got a segmentation fault when it executed an assembly language call instruction. Using gdb I was able to disassemble the instructions at the called address. Why can gdb disasemble instructions at a call address and a call to that address fails with a segmentation fault?  Is this a kernel problem?  I am using kernel version 2.2.15.  Any suggestions would be appreciated. I tried kernel 2.4.4 and the same thing happens.  I have searched this mailing list archive and did find some posts about segmentation faults/ kernel bugs, but they did not resolve this problem.  I use egcs 1.1-2 and ld 2.9.5 versions.

Re: Is this a kernel problem? segmentation fault

[Terje Eggestad]

Bugs in the kernel may cause seg fault, but when that happens you should
get an oops in /var/log/messages and/or on the console.

ons, 2001-11-14 kl. 02:40 skrev Donald Harter:
    I started by debugging this program where I was getting a segmentation  fault.  I used gdb and traced the bug to a call instruction.  I dissasembled  the code and stepped through the instructions.  The program  got a segmentation  fault when it executed an assembly language call instruction. Using gdb  I was able to disassemble the instructions at the called address. Why can  gdb disasemble instructions at a call address and a call to that address  fails with a segmentation fault?  Is this a kernel problem?  I am using kernel  version 2.2.15.  Any suggestions would be appreciated. I tried kernel 2.4.4  and the same thing happens.  I have searched this mailing list archive  and did find some posts about segmentation faults/ kernel bugs, but  they did not resolve this problem.  I use egcs 1.1-2 and ld 2.9.5 
    versions.
    
    
    
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    -- 
   
_________________________________________________________________________
    
    Terje Eggestad                  terje.eggestad@scali.no
    Scali Scalable Linux Systems    http://www.scali.com
    
    Olaf Helsets Vei 6              tel:    +47 22 62 89 61 (OFFICE)
    P.O.Box 70 Bogerud                      +47 975 31 574  (MOBILE)
    N-0621 Oslo                     fax:    +47 22 62 89 51
    NORWAY            
   
_________________________________________________________________________

Re: Is this a kernel problem? segmentation fault

[Roman Zippel]

Hi,

On Tue, 13 Nov 2001, Donald Harter wrote:

> Using gdb I was able to disassemble the instructions at the called
> address. Why can gdb disasemble instructions at a call address and a
> call to that address fails with a segmentation fault?

Check the memory protection settings in /proc/[pid]/maps, when gdb
accesses that memory with ptrace these settings are ignored.

bye, Roman

Re: Is this a kernel problem? segmentation fault

[Andreas Schwab]

"Donald Harter" <dharter@lycos.com> writes:

|>      I started by debugging this program where I was getting a
|>      segmentation fault.  I used gdb and traced the bug to a call
|>      instruction.  I dissasembled the code and stepped through the
|>      instructions.  The program got a segmentation fault when it
|>      executed an assembly language call instruction. Using gdb I was
|>      able to disassemble the instructions at the called address. Why
|>      can gdb disasemble instructions at a call address and a call to
|>      that address fails with a segmentation fault?

Perhaps a stack overflow, or stack pointer is pointing to lala land.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5