How to dump core on crash?
Hi, the stability problems I had posted a week ago are occuring again, and I also got at least one more occurrence of the ominous assertion faileure in modcall.c Sow I would like to provide Alan with a core dump/bt, but I couldn't manage to produce one. Here's what I have tried so far: - enable coredumps in /etc/freeradius.conf (logfile confirms it) - make /etc/freeradius writable for the freerad group - change login shell of user freerad to /bin/bash for a test, login and make a 'sleep 1000' crash by sending a SIGSEGV -- this produces a core file, so ulimits should be o.k. - Look under /proc/<freerad-pid>/cwd to figure out the current working directory of the main freerad process, it's always '/'. So where should I expect to find a core dump? Thanks, Martin
Martin Pauly <pauly@hrz.uni-marburg.de> wrote:
- Look under /proc/<freerad-pid>/cwd to figure out the current working directory of the main freerad process, it's always '/'.
So where should I expect to find a core dump?
If you've set "user" or "group" in radiusd.conf, you won't get a core file. I'd suggest running the server in debugging mode, and redirecting the output to /dev/null. That way you control which directory it runs in, and you're guaranteed to get a core file (assuming ulimit is set) Alan DeKok.
So where should I expect to find a core dump?
If you've set "user" or "group" in radiusd.conf, you won't get a core file. o.k., I have unset the above and simply done everything by hand so I was able to produce a core file this time. I also could get gdb to backtrace it. So I am waiting for the next event now (missed one 3 hours ago :.|), so I expect this to happen again.
Martin
On Tuesday 11 October 2005 23:28, Martin Pauly wrote:
o.k., I have unset the above and simply done everything by hand so I was able to produce a core file this time. I also could get
sorry for the long delays, I was on vacation last week. I got a real core dump now, but the gdb output doesn't look very interesting. I suppose I am using a stripped binary; the only thing I changed in debian/rules was to add '--disable-shared'. So I'm afraid this might deprive the debugger of some important information. ===================== GDB output ============================== rsf2:/# gdb --core core.real-crash GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux". Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `/usr/sbin/freeradius'. Program terminated with signal 11, Segmentation fault. #0 0x4023df3e in ?? () #1 0x00000004 in ?? () #2 0x00000000 in ?? () #3 0x40420301 in ?? () #4 0x081515e0 in ?? () ... [omitting 2000 lines of this kind] ... #2300 0x00000000 in ?? () #2301 0x00000000 in ?? () #2302 0x00000000 in ?? () Error accessing memory address 0xbf400000: No such file or directory. Quit (gdb) Cheers, Martin -- Dr. Martin Pauly Fax: 49-6421-28-26994 HRZ Univ. Marburg Phone: 49-6421-28-23527 Hans-Meerwein-Str. E-Mail: pauly@HRZ.Uni-Marburg.DE D-35032 Marburg
Martin Pauly <pauly@hrz.uni-marburg.de> wrote:
sorry for the long delays, I was on vacation last week. I got a real core dump now, but the gdb output doesn't look very interesting. I suppose I am using a stripped binary;
Yup. The default install is to strip the binaries.
the only thing I changed in debian/rules was to add '--disable-shared'. So I'm afraid this might deprive the debugger of some important information.
That shouldn't matter.
#4 0x081515e0 in ?? () ... [omitting 2000 lines of this kind]
That looks suspiciously like a stacvk overflow. Maybe there's an infinite recursion problem somewhere? Alan DeKok.
participants (2)
-
Alan DeKok -
Martin Pauly