bug-tar
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-tar] Segfault in gtar 1.23 on fBSD 8.0


From: noordsij
Subject: [Bug-tar] Segfault in gtar 1.23 on fBSD 8.0
Date: Thu, 02 Sep 2010 22:47:26 +0300
User-agent: RoundCube Webmail/0.2.1

Dear GNU tar maintainer(s) / fBSD gtar port maintainer(s),

While trying to use gtar (version 1.23) for backup purposes on FreeBSD 8.0
(I know, will update soon), because of the listed-incremental option and to
maintain compatibility with non-BSD systems, gtar keeps segfaulting for my
set of options, specifically when using --listed-incremental.

(This is not the getline related crash I reported for version 1.22)

In this case I have not found a fix yet, and am trying to reproduce it on
something smaller than a full system backup, as a testcase.

The backtrace looks as follows:

gdb /usr/local/bin/gtar ../gtar.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 "amd64-marcel-freebsd"...
Core was generated by `gtar'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libintl.so.9...done.
Loaded symbols for /usr/local/lib/libintl.so.9
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x000000000043ca68 in hash_string (string=0x0, n_buckets=53) at
hash.c:427
427       for (; (ch = *string); string++)
(gdb) bt
#0  0x000000000043ca68 in hash_string (string=0x0, n_buckets=53) at
hash.c:427
#1  0x00000000004138e9 in hash_directory_canonical_name (entry=0x800c67b80,
n_buckets=53) at incremen.c:219
#2  0x000000000043d295 in hash_find_entry (table=0x800c240b0,
entry=0x800c67b80, bucket_head=0x7fffffffe318, 
    delete=false) at hash.c:788
#3  0x000000000043d865 in hash_insert (table=0x800c240b0,
entry=0x800c67b80) at hash.c:1042
#4  0x0000000000413cf3 in note_directory (name=0x800c61940 "", mtime=
      {tv_sec = 1266865014, tv_nsec = 35823938}, dev=1451615477, ino=3,
nfs=false, found=false, 
    contents=0x800c61950 "Y.cshrc") at incremen.c:327
#5  0x000000000041655d in read_incr_db_2 () at incremen.c:1267
#6  0x00000000004167da in read_directory_file () at incremen.c:1343
#7  0x000000000041d37d in collect_and_sort_names () at names.c:904
#8  0x000000000040bdd0 in create_archive () at create.c:1283
#9  0x000000000042636a in main (argc=48, argv=0x7fffffffe690) at tar.c:2605

What is curious perhaps is in frame 4 the empty name "" ? Filesystem is
ZFS. This has otherwise been running fine for months using this exact same
setup, until a ports upgrade where gtar was bumped to 1.23 (among of course
its dependencies and such). Now the initial full backup works fine, but all
following incremental ones segfault. 

The core dump is 2 megs, in case it helps to look at it.

If you have any suggestion on what I could try, I would be happy to do so.

If I find a smaller test case I will follow up on this.

Best regards,
Dennis







reply via email to

[Prev in Thread] Current Thread [Next in Thread]