clamd+libunrar signal 4: how to debug?

Dmitry Pryanishnikov dmitry at atlantis.dp.ua
Wed May 31 00:37:05 PDT 2006


Hello!

   I'm getting pretty repeatable abnormal termination of clamd
(ports/security/clamav) compiled with libunrar support on signal 4 
(4.11-RELEASE/i386). I've built both clamd and libunrar with debugging info:

CFLAGS+= -g
LDFLAGS+= -g
STRIP=

and got the core. However I'm not sure how to interpret gdb output:

GNU gdb 4.18 (FreeBSD)
Copyright 1998 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-unknown-freebsd"...Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs
Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf

Core was generated by `clamd'.
Program terminated with signal 4, Illegal instruction.
Reading symbols from /usr/local/lib/libclamav.so.1...done.
Reading symbols from /usr/local/lib/libunrar.so...done.
Reading symbols from /usr/lib/libz.so.2...done.
Reading symbols from /usr/lib/libbz2.so.1...done.
Reading symbols from /usr/local/lib/libgmp.so.7...done.
Reading symbols from /usr/lib/libc_r.so.4...done.
Reading symbols from /usr/lib/libstdc++.so.3...done.
Reading symbols from /usr/lib/libm.so.2...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0  0x280c71f5 in VolNameToFirstName (VolName=0x902a43f "",
     FirstName=0x902a43f "", NewNumbering=true) at pathfn.cpp:564
564	}
(gdb) path /usr/ports/archivers/libunrar/work/unrar
Executable and object file path: /usr/ports/archivers/libunrar/work/unrar:/home/root/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin
Current language:  auto; currently c++
(gdb) bt full
#0  0x280c71f5 in VolNameToFirstName (VolName=0x902a43f "",
     FirstName=0x902a43f "", NewNumbering=true) at pathfn.cpp:564
 	VolName = 0xbfad7c9c ""
 	VolNumStart = Cannot access memory at address 0xbfac7ccc.
----------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Does this message suggest that program ran out of the stack? I doubt it, 
process stack limit is pretty high (268435456 bytes). However, application
is multithreaded, so I'm not sure (maybe, thread runs out of it's stack)?

(gdb) fr 0
#0  0x280c71f5 in VolNameToFirstName (VolName=0x902a43f "",
     FirstName=0x902a43f "", NewNumbering=true) at pathfn.cpp:564
564	}
(gdb) list
559	      if (Truncate)
560	        *VerTextW=0;
561	    }
562	  }
563	  return(Version);
564	}
565 
566 
567	#ifndef SFX_MODULE
568	char* VolNameToFirstName(const char *VolName,char *FirstName,bool NewNumbering)

Does this listing suggest that no code of VolNameToFirstName() has actually 
been executed yet? What other gdb commands can I use to narrow down the 
problem?


Sincerely, Dmitry
-- 
Atlantis ISP, System Administrator
e-mail:  dmitry at atlantis.dp.ua
nic-hdl: LYNX-RIPE


More information about the freebsd-hackers mailing list