home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sources / wanted / 4280 < prev    next >
Encoding:
Internet Message Format  |  1992-09-10  |  3.0 KB
  1. Xref: sparky comp.sources.wanted:4280 comp.unix.questions:10891 comp.windows.x:16457
  2. Newsgroups: comp.sources.wanted,comp.unix.questions,comp.windows.x
  3. Path: sparky!uunet!cs.utexas.edu!torn!cunews!nrcnet0!bnrgate!bcars267!bmdhh243!agc
  4. From: agc@bmdhh298.bnr.ca (Alan Carter)
  5. Subject: Re: Stack Traceback program wanted
  6. Message-ID: <1992Sep10.094948.3497@bnr.uk>
  7. Sender: news@bnr.uk (News Administrator)
  8. Nntp-Posting-Host: bmdhh298
  9. Organization: BNR-Europe-Limited, Maidenhead, England
  10. References: <1992Sep9.143656.20352@kocrsv01.delcoelect.com> <1992Sep09.172755.17887@bnr.uk> <1992Sep9.193434.2713@kocrsv01.delcoelect.com>
  11. Date: Thu, 10 Sep 1992 09:49:48 GMT
  12. Lines: 64
  13.  
  14. In article <1992Sep9.193434.2713@kocrsv01.delcoelect.com>, c23st@kocrsv01.delcoelect.com (Spiros Triantafyllopoulos) writes:
  15. |> In article <1992Sep09.172755.17887@bnr.uk> agc@bmdhh298.bnr.ca (Alan Carter) writes:
  16. |> >In article <1992Sep9.143656.20352@kocrsv01.delcoelect.com>, c23st@kocrsv01.delcoelect.com (Spiros Triantafyllopoulos) writes:
  17. |> >|> we're looking for a program to do stack a trace before it coredumps. We
  18. |> >|> would like to see, for example, the sequences of calls that resulted
  19. |> >|> in the program to bomb. 
  20. |> >
  21. |> >The compiler will do this for you. Compile your code
  22. |> >
  23. |> >   cc -g -o spiros spiros.c
  24. |> >
  25. |> >Then after you have got your coredump, use adb,
  26. |> >
  27. |> >   adb spiros
  28. |> >
  29. |> >and give the command 
  30. |> >   
  31. |> >   $c
  32. |> >
  33. |> (judging from my weight, adb would probably go out of memory :-). But
  34. |> seriously, what we have in mind is really to compile such a function in
  35. |> our program and do it 'on demand' every time it crashes, so we can have
  36. |> a log of what happened. 
  37. |> 
  38. |> We can always ask the users to run a utility on the core file and see
  39. |> what happens afterwards... maybe a little script to examine core and 
  40. |> do the $c command.
  41. |> 
  42. |> Is the core format published anywhere?
  43.  
  44. What about 
  45.  
  46.    cd prog_pwd
  47.    var=0
  48.    while true
  49.    do
  50.       if test -f core
  51.       then
  52.          mv core logcore$var
  53.          var=`expr $var + 1`
  54.       fi
  55.       sleep 300
  56.    done
  57.  
  58. Which will keep your core files as logcore0, logcore1 etc. You can then
  59. analyse them at your convenience. Trapping the signal and interpreting
  60. your stack in the handler would be far more awkward, and inherently
  61. non-portable. You'll probably have to interpret your stack frames 
  62. yourself - the format in core files is normally interpreted by the adb
  63. like tools and is not usually published. Programs are not supposed to
  64. play around with their own stacks at all :-) The useful thing about 
  65. saving the whole cores is that you will be able to do more investigation,
  66. like examining variables.
  67.  
  68.    Alan
  69.  
  70. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  71.    Maidenhead itself is too snobby to be pleasant. It is the haunt of the
  72.    river swell and his overdressed female companion. It is the town of showy
  73.    hotels, patronized chiefly by dudes and ballet girls. 
  74.  
  75.    Three Men In A Boat, Jerome K. Jerome, 1889
  76. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  77.  
  78.