PennMUSH Community

Ticket #7537 (closed bug: fixed)

Opened 9 months ago

Last modified 9 months ago

1.8.3p6 segfaulting on FreeBSD 6.1

Reported by: Yuriko Assigned to:
Priority: crash Milestone: 1.8.3p7
Keywords: Cc:
Visibility: Public

Description

@shutdown/reboot after patching had worked fine, but now I'm running into this when trying to start up fresh after a full shutdown. The netmud binary doesn't output anything; it just immediately segfaults when run. Stack trace from the core dump is thus:

shoujoai@lilith:~/pennmush/game $ gdb netmush netmud.core
GNU gdb 6.1.1 [FreeBSD]
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-marcel-freebsd"...

warning: core file may not match specified executable file.
Core was generated by `netmud'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libpcre.so.0...done.
Loaded symbols for /usr/local/lib/libpcre.so.0
Reading symbols from /lib/libcrypt.so.3...done.
Loaded symbols for /lib/libcrypt.so.3
Reading symbols from /usr/local/lib/libintl.so.8...done.
Loaded symbols for /usr/local/lib/libintl.so.8
Reading symbols from /lib/libm.so.4...done.
Loaded symbols for /lib/libm.so.4
Reading symbols from /usr/lib/libssl.so.4...done.
Loaded symbols for /usr/lib/libssl.so.4
Reading symbols from /lib/libcrypto.so.4...done.
Loaded symbols for /lib/libcrypto.so.4
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x28353880 in __vfprintf () from /lib/libc.so.6
#1  0x282ed4ec in vsnprintf () from /lib/libc.so.6
#2  0x080b6e9d in do_rawlog (logtype=0, fmt=0x80ec1ce "%s:%s") at log.c:202
#3  0x080b779c in penn_perror (err=0x80fcfad "fcntl") at log.c:508
#4  0x080e2ed8 in lock_fp (f=0x2836d2f0, what=true) at wait.c:164
#5  0x080e2ef8 in lock_file (f=0x2836d2f0) at wait.c:179
#6  0x080b6f7f in do_rawlog (logtype=674681584, fmt=0x80ec1ce "%s:%s") at log.c:242
#7  0x080b779c in penn_perror (err=0x80fcfad "fcntl") at log.c:508
#8  0x080e2ed8 in lock_fp (f=0x2836d2f0, what=true) at wait.c:164
#9  0x080e2ef8 in lock_file (f=0x2836d2f0) at wait.c:179
#10 0x080b6f7f in do_rawlog (logtype=674681584, fmt=0x80ec1ce "%s:%s") at log.c:242
(repeats last four lines ad infinitum)

Debugging isn't my forte, but it seems like the recent fix to Ticket #7456 might be at fault. Reverting to p5 let me get up again, but thats a non-ideal solution.

Change History

01/20/08 21:12:44 changed by raevnos

  • status changed from new to closed.
  • type changed from incoming to bug.
  • resolution set to fixed.
  • milestone set to 1.8.3p7.

Doh. Recursive use of error reporting functions breaks badly on errors.