home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / linux / 16174 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  2.8 KB
  1. Path: sparky!uunet!ogicse!decwrl!csus.edu!netcom.com!aclark
  2. From: aclark@netcom.com (Al Clark)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: SEGV in library routines
  5. Message-ID: <1992Nov9.192911.19545@netcom.com>
  6. Date: 9 Nov 92 19:29:11 GMT
  7. Article-I.D.: netcom.1992Nov9.192911.19545
  8. References: <1992Nov9.081513.22863@netcom.com>
  9. Organization: Netcom - Online Communication Services  (408 241-9760 guest)
  10. Lines: 53
  11.  
  12. In article <1992Nov9.081513.22863@netcom.com> zmbenhal@netcom.com (Zeyd M. Ben-Halim) writes:
  13. >   
  14. >This was on the mailing list. Since I've heard no explaination I'm asking here:
  15. >
  16. >      From: d88-man@nada.kth.se
  17. >      Sender: owner-linux-activists@joker.cs.hut.fi
  18. >      X-Note1: Remember to put 'X-Mn-Key: normal' to your mail body or header
  19. >      X-Mn-Key: NORMAL
  20. >   
  21. >   
  22. >      I have tried compiling some X-programs (e.g SRGP-library, olvwm,
  23. >      xsokoban etc.)  The compilation works ok, but when trying to run the
  24. >      resulting executable just give segmentation fault, core dumped...
  25. >      Using gdb shows that the seg. fault appears in a function called
  26. >      _end().  (What is that function doing ?) It seems that the call to
  27. >      ^^^^^^
  28. >I got similar error trying to run equel (part of ingres RDBMS). The stack
  29. >showed:
  30. >sys_nerr
  31. >_end
  32. >_end
  33. >But sys_nerr is AN integer. gdb says that it's a char. In the library is
  34. >appears as T (text; aka code???)
  35. >
  36.     [ remaining info deleted ]
  37.  
  38.     I am far from an expert, so if anyone can correct me, jump
  39.     right in, but _end is normally the symbol defining the end
  40.     of the data segment.  The program is made up of a text
  41.     segment and an initialized data segment, amongst others, and
  42.     the area right after the data segment, (that is, right after
  43.     the _end symbol) is the address area from which more memory
  44.     is allocated.  You should never be executing code in this
  45.     area, which is sufficient to cause a segment fault.
  46.     Somehow, you are jumping to a data address.  Note that
  47.     sys_nerr is a data address, defined in errlist.o, from
  48.     libc.  I think the T merely tells the linker that this is
  49.     an address that is to be used to resolve undefined addresses.
  50.  
  51.     So this means that the stack backtrace is consistent with a
  52.     segment fault.  Look further back on the trace; common
  53.     reasons for such probs are calling a subroutine with the
  54.     wrong number or type of arguments.  For example, if you call
  55.     a subroutine that is expecting two words of arguments, and
  56.     you only supply one, the return address on the stack can get
  57.     misused or corrupted, and you transfer control to some non
  58.     text segment address and, there you go, segment violation
  59.     and segment fault interrupt.  Ansi C should detect such
  60.     cases, but the code you're porting may be old.
  61.  
  62.     Good luck.
  63. -- 
  64. Al - aclark@netcom.com - My opinions are my own.
  65.