Re: Possible GCC problem/kernel problem?

From: Wolfram Schroeder (ws@Informatik.Uni-Bremen.DE)
Date: 12/29/95


In the Circle mud list you wrote ...


   Occasionally the mud crashes and when i do a backtrace i get this, and it
   doesn't just happen in create_money() occasionally in other functions it
   will bomb out, and it doesn't always happen everytime in create_money().
   I did notice it happen a few weeks after switching from gcc 2.5.6 to 2.7.0
   I'm using Linux 1.2.13, anybody else seen/know why or what causes this crash?

   #0  0x60019b0c in end ()
   #1  0x2b in ?? ()
   #2  0x6000a1fa in end ()
   #3  0xada78 in __gnu_calloc (__nmemb=43, __n=1) at /usr/include/stdlib.h:217
   #4  0xac4a0 in str_dup (
       source=0xbffff780 "A little pile of gold coins is lying here.")
       at utils.c:75
   #5  0x76550 in create_money (amount=34) at handler.c:1202
   #6  0x6e374 in make_corpse (ch=0x358600) at fight.c:289
   #7  0x6e637 in raw_kill (ch=0x358600, killer=0x35b200) at fight.c:345
   #8  0x6e7e1 in die (ch=0x358600, killer=0x35b200) at fight.c:365
   #9  0x70002 in damage (ch=0x35b200, victim=0x358600, dam=18, attacktype=307)
       at fight.c:765
   #10 0x70a0d in hit (ch=0x35b200, victim=0x358600, type=-1) at fight.c:902
   #11 0x70c6d in perform_violence () at fight.c:943
   #12 0x28c5 in game_loop (mother_desc=3) at comm.c:542
   #13 0x1766 in init_game (port=4000) at comm.c:213
   #14 0x1664 in main (argc=3, argv=0xbffffd2c) at comm.c:185



 Well, given that the pointers are correct, i suggest to check out
all sprintf's entered before. Once i had a similar problem with linux,
i sprintf'ed into an arbitrary pointer, which produced no segfault
because the kernel, and printf and similar *is* a kernel function,
may write to every place in the memory. The effect i had was, that
"new" in C++ crashed with a similar looking backtrace. I don't know
if my theory is correct at all, or if it does apply for any newer
kernel, only correcting the sprintf found quite some steps before
helped. Maybe try callocing memory some place before, and if it
"works", start a binary search along the execution path :-)

Good luck,

Wolfram Schroeder
Karl@Realm of Magic     b11.informatik.uni-bremen.de 4000



This archive was generated by hypermail 2b30 : 12/07/00 PST