1Program xy fails with segmentation fault, what can I do? 2======================================================== 3 4About 5----- 6 7This document is intended for Husky users that experience a "segmentation 8fault" type error in a Husky program. It describes how than can use gdb to 9provide a bug report to the developers that is much more useful than a simply 10"I did this and that and then got a segfault". 11 12Prerequistes 13------------ 14 15Using gdb to debug a segmentation fault works on all Unix systems where gcc 16is available, and on OS/2 if makefile.emx or the Husky build process is 17used. It does not work on OS/2 if makefile.emo or a non-gcc compiler is used. 18On Windows gdb may used in Cygwin only. On Unix systems where gcc is not 19available, a similar procedure ususally works with a vendor debugger like 20dbx, but treating this is outside the scope of this document. 21 22In order to use gdb to create a useful bug report you first must recompile 23the Husky source. If you never compiled your Husky software on your own, you 24should first master that task and then return to this document later-on. In 25the following, I will assume that you have a working setup of a huskymak.cfg 26and have successfully managed to compile and install all software in question 27(the failing program and smapi and fidoconf) by using the Husky build process 28makefile. The following also does not cover makefile.emx on OS/2 (but it does 29cover Makefile with huskymak.cfg on OS/2), but if you really need to use 30makefile.emx on OS/2, just drop me a mail. 31 32 33Enabling Debugging in Huskymak.cfg 34---------------------------------- 35 36Your huskymak.cfg should contain one line setting the DEBCFLAGS variable. 37one setting the DEBLFLAGS variable, and one setting the DEBUG variable. If it 38does not, your huskymak.cfg is VERY outdated and you should set up a fresh 39copy by using the latest huskybse module. 40 41Then, you must sure that those lines contain the following values: 42 43DEBCFLAGS=-g -c 44DEBLFLAGS=-g 45 46Alternatively, the following values can also be used. On systems where gcc 47and gdb is used, they are 100% equivalent, while on Unix systems with a 48vendor cc and a vendor dbx those won't work, that's why I usually just use 49-g: 50 51DEBCFLAGS=-ggdb -c 52DEBLFLAGS=-ggdb 53 54After you have done so, you can change the DEBUG variable to read 55 56DEBUG=1 57 58 59Compiling and installing debug binaries 60--------------------------------------- 61 62Now, you must do a "make clean; make; make install" in each library 63directory, i.E. usually in the smapi and in the fidoconf directory. 64 65This will replaced your installed non-debugging libraries with debugging 66versions of the libraries. This does absolute no harm to your installation 67(besides of a usually invisible small performance penalty) as long as the 68debugging versions are compiled from the same source code as your already 69installed non-debugging versions. 70 71After that, change to the directoy of the program that you want to debug and 72to a "make clean; make; make install". Debugging is also possible without 73installing, but for simplicty I will not cover this in here. 74 75 76Creating a core file 77-------------------- 78 79Then, you can do whatever you do to create the segfault. After you recreated 80the failure, you should find a file anmed "core" or "PROGRAMNAME.core" (like 81"hpt.core") or "core.programnam" in the directory which was the current 82directory when the program ran. Try your home directory, your fido user's 83home directory, or similar places. 84 85If you cannot find such a core file, you must run "umlimit -c unlimited" 86before executing the failing program. You can type this by hand, but be aware 87that this only affects the current running shell, so it's probably best to 88place this command into the script which calls the failing program directly 89before the failing program is called. Also note that this only works in 90Korn/Bourne-Shell derivatives like sh, ksh, bash. It does not work for the C 91shell. C shell is not covered in this document. 92 93After this, you really should be able to find a core file. If not, you can 94try the "debugging interactivly" section below instead. 95 96Once you have found the core file, you can type "gdb <name-of-program> <name 97of corefile>", like "gdb hpt core". It is important that you specify the 98correct files here, especially the correct executable. Users often tend to 99not install the debugging executable, but run it from their home directory to 100create the core file. In thise case, "gdb hpt core" would NOT debug the 101debugging version in the home, but the installed non-debugging version. So in 102case of doubt, specify the full path to the debugging version of the 103executable. If in doubt, you can just look at the directory (ls -l) entry of 104the executables - the debugging version should be much larger than the 105non-debugging version. 106 107 108Reading the core file with gdb 109------------------------------ 110 111After entering the gdb command from above, gdb should start up and finally 112present you with a prompt like in the following example 113 114 tobi@lilapause:~$ gdb ./testprogram core 115 GNU gdb 4.17 116 Copyright 1998 Free Software Foundation, Inc. 117 GDB is free software, covered by the GNU General Public License, and you are 118 welcome to change it and/or distribute copies of it under certain conditions. 119 Type "show copying" to see the conditions. 120 There is absolutely no warranty for GDB. Type "show warranty" for details. 121 This GDB was configured as "alphaev56-dec-osf4.0e"... 122 Core was generated by `testprogram'. 123 Program terminated with signal 11, Segmentation fault. 124 Reading symbols from /usr/shlib/libc.so...done. 125 #0 0x12000112c in testfn (ptr=0x0) at test.c:3 126 3 *ptr = 23; 127 (gdb) 128 129You should NOT see any message like "no debugging symbols found" when 130starting up gdb. If you do, something went wrong. Either your huskymak.cfg 131has not the right flags, or you used the wrong executable. Make sure that the 132executable you used to create the core file and that you supplied as argument 133to gdb is much larger than usually. If you stil thing you did everything 134right, you might have a flaky gdb installation. Some SuSE Linux distributions 135had a buggy gdb per default, but update rpm's for gdb are available for those 136versions of SuSE linux. 137 138Now, at the (gdb) prompt, type (gdb) where: 139 140 (gdb) where 141 #0 0x12000112c in testfn (ptr=0x0) at test.c:3 142 #1 0x12000116c in main () at test.c:9 143 (gdb) 144 145Use this information to contact us in FIDOSOFT.HUSKY or via netmail/email. It 146will be very valuable. 147 148As you can see, in the example output from the where command from above, we 149see the function name (testfn), file name (test.c) and line number (3) where 150the program crashed. Sometimes, this information is not visible, and you will 151simply see a lot of ?? signs instead of the relevant information. In this 152case, you should follow the information in the following sections. Otherwise, 153you are finished at this point. 154 155 156Debugging interactively 157----------------------- 158 159Debugging a core file has the advantage that it is a post mortem debugging 160method, that is you can let your system run normally, and it will throw a 161core file when it dies, which you can debug afterwards. 162 163However, this method sometimes does not work. Either you cannot convince your 164system into throwing a core file, or the core file is useless (showing just 165???? signs on the where command instead of proper information). In this case, 166you must debug the problem interactively. 167 168To do so, you must create a szenario in which invoking the program with a 169specific command line will create the crash. Then, recreate the szenario but 170don't recreate the crash, but load the program into gdb without supplying a 171core file as argument, like in "gdb hpt" or "gdb /usr/local/src/hpt/hpt". 172 173Again, make sure that no "no debugging symbols found" message pops up. If it 174does, read in the previous section what to do about it. 175 176At the (gdb) prompt, you can now type "set args <ARGUMENTS>" to supply any 177command line arguments to the program, like e.g. "set args toss" if you would 178debug hpt and the crash occurs upon tossing. 179 180Then you just type "run", and the program should sooner or stater stop like 181in the following example: 182 183 184tobi@lilapause:~$ gdb hpt 185GNU gdb 4.17 186Copyright 1998 Free Software Foundation, Inc. 187GDB is free software, covered by the GNU General Public License, and you are 188welcome to change it and/or distribute copies of it under certain conditions. 189Type "show copying" to see the conditions. 190There is absolutely no warranty for GDB. Type "show warranty" for details. 191This GDB was configured as "alphaev56-dec-osf4.0e"... 192(gdb) set args toss 193(gdb) run 194Starting program: /home/tobi/bin/hpt toss 195 196Program received signal SIGSEGV, Segmentation fault. 1970x120001168 in testfn () at test.c:6 1986 a[i]=231; 199(gdb) 200 201then, you can again type "where" and send us the output: 202 203(gdb) where 204#0 0x120001168 in testfn () at test.c:6 205#1 0x1200011bc in main () at test.c:6 206 207In case that you still only see questionmarks, you have a really hard 208problem. In that case you probably can't do any more (well, of course if you 209are a C developer you could start single stepping the program by typing 210"break main" bevore "run" and using "s" (step into) and "n" (step over) to 211find out where it crashes). Contact us to get further assistance 212 213[EOF] 214