Comments (11)
Thanks for the report, and especially for all the git bisect
work! I'm installing a 32-bit distro so that I can reproduce this.
I see that your Linux kernel is relatively recent (5.4.10), although I'm guessing that linode installed that automatically. Could I ask what distro you're running? It might be useful for me to look up which version of glibc it comes with.
from tarsnap.
@0xkag Can you check whether this error goes away if you delete the "cache" file in the tarsnap cache directory? (To be clear: Keep the "directory" file.)
My suspicion is that this is happening when the chunkification cache says "skip past the end of the chunks we have cached".
from tarsnap.
Thanks again, @0xkag. I've discovered (another?) problem with i386, at least on Ubuntu 14.04 "trusty". I'll get back to you when I've finished investigating i386 on various distros.
from tarsnap.
I have a fix for this issue, and the other one I discovered (with --list-archives
); add
#include "platform.h"
to the top of tar/glue/tape.c
and tar/ccache/ccache_entry.c
.
However, I'm not certain that's the best fix; I'm currently investigating exactly where the problems arose[1] and looking for other cases. I might find a better option.
[1] in the case of lseek
, the problem is probably that _FILE_OFFSET_BITS
wasn't getting set before we included sys/types.h
or sys/stat.h
or fcntl.h
. The cause of that was my cleaning up bsdtar_platform.h
-> (platform.h
or removal), and I'd forgotten that the glibc feature_test_macros
required values to be defined before any header files.
from tarsnap.
Hi @gperciva,
I see that your Linux kernel is relatively recent (5.4.10), although I'm guessing that linode installed that automatically. Could I ask what distro you're running? It might be useful for me to look up which version of glibc it comes with.
Yes, the kernel is Linode's 32-bit latest, and changes to whatever latest is each reboot. Last reboot 26 days ago.
% lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.12 (stretch)
Release: 9.12
Codename: stretch
from tarsnap.
Hi @cperciva,
@0xkag Can you check whether this error goes away if you delete the "cache" file in the tarsnap cache directory? (To be clear: Keep the "directory" file.)
Still happens:
~/.tarsnap% mv cache cache.bak
~/.tarsnap% /path/to/script
<snip>
tarsnap: lseek(Maildir/dovecot-uidvalidity): Invalid argument
<snip>
from tarsnap.
I have a fix for this issue, and the other one I discovered (with
--list-archives
); add#include "platform.h"
to the top of
tar/glue/tape.c
andtar/ccache/ccache_entry.c
.
When I apply this diff:
diff --git a/tar/ccache/ccache_entry.c b/tar/ccache/ccache_entry.c
index 373fd89..068a01f 100644
--- a/tar/ccache/ccache_entry.c
+++ b/tar/ccache/ccache_entry.c
@@ -1,3 +1,5 @@
+#include "platform.h"
+
#include <sys/stat.h>
#include <errno.h>
diff --git a/tar/glue/tape.c b/tar/glue/tape.c
index cb89a05..12d80dc 100644
--- a/tar/glue/tape.c
+++ b/tar/glue/tape.c
@@ -1,3 +1,5 @@
+#include "platform.h"
+
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
It runs for a while, appears to do something, and then segfaults. I wasn't yet able to capture a core.
from tarsnap.
Here's a backtrace. I've removed/edited a few personalized paths.
% gdb -c ~/core ~/.root/bin/tarsnap
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
<snip>
This GDB was configured as "i686-linux-gnu".
<snip>
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __mempcpy_ia32 () at ../sysdeps/i386/i686/multiarch/../mempcpy.S:50
50 ../sysdeps/i386/i686/multiarch/../mempcpy.S: No such file or directory.
@gdb-peda$ bt
#0 __mempcpy_ia32 () at ../sysdeps/i386/i686/multiarch/../mempcpy.S:50
#1 0xb7ae2d7b in _IO_new_file_xsputn (f=0xa59d70, data=0x1, n=0x1) at fileops.c:1327
#2 0xb7ad797d in __GI__IO_fwrite (buf=<optimized out>, size=<optimized out>, count=<optimized out>, fp=<optimized out>) at iofwrite.c:39
#3 0x004c4f35 in callback_write_data (cookie=0xbf86e70c, s=0xf5d148 "/path/to/a/file/that/I/have/redacted", slen=0x49, rec=0xb9df08)
at tar/ccache/ccache_write.c:181
#4 0x004f8423 in foreach_internal (n=<optimized out>, func=func@entry=0x4c4ec0 <callback_write_data>, cookie=cookie@entry=0xbf86e70c, keybuf=<optimized out>, keypos=0x49)
at lib/datastruct/patricia.c:222
#5 0x004f847d in foreach_internal (n=<optimized out>, func=func@entry=0x4c4ec0 <callback_write_data>, cookie=cookie@entry=0xbf86e70c, keybuf=<optimized out>, keypos=0x27)
at lib/datastruct/patricia.c:224
#6 0x004f847d in foreach_internal (n=<optimized out>, func=func@entry=0x4c4ec0 <callback_write_data>, cookie=cookie@entry=0xbf86e70c, keybuf=<optimized out>, keypos=0x26)
at lib/datastruct/patricia.c:224
#7 0x004f847d in foreach_internal (n=<optimized out>, func=func@entry=0x4c4ec0 <callback_write_data>, cookie=cookie@entry=0xbf86e70c, keybuf=<optimized out>, keypos=0x26)
at lib/datastruct/patricia.c:224
#8 0x004f847d in foreach_internal (n=<optimized out>, func=func@entry=0x4c4ec0 <callback_write_data>, cookie=cookie@entry=0xbf86e70c, keybuf=<optimized out>, keypos=0x23)
at lib/datastruct/patricia.c:224
#9 0x004f847d in foreach_internal (n=<optimized out>, func=func@entry=0x4c4ec0 <callback_write_data>, cookie=cookie@entry=0xbf86e70c, keybuf=<optimized out>, keypos=0x1c)
at lib/datastruct/patricia.c:224
#10 0x004f847d in foreach_internal (n=<optimized out>, func=func@entry=0x4c4ec0 <callback_write_data>, cookie=cookie@entry=0xbf86e70c, keybuf=<optimized out>, keypos=0x1c)
at lib/datastruct/patricia.c:224
#11 0x004f847d in foreach_internal (n=<optimized out>, func=func@entry=0x4c4ec0 <callback_write_data>, cookie=cookie@entry=0xbf86e70c, keybuf=<optimized out>, keypos=0x16)
at lib/datastruct/patricia.c:224
#12 0x004f847d in foreach_internal (n=<optimized out>, func=func@entry=0x4c4ec0 <callback_write_data>, cookie=cookie@entry=0xbf86e70c, keybuf=<optimized out>, keypos=0xe)
at lib/datastruct/patricia.c:224
#13 0x004f8817 in patricia_foreach (P=0xa5a610, func=0x4c4ec0 <callback_write_data>, cookie=0xbf86e70c) at lib/datastruct/patricia.c:489
#14 0x004c5082 in ccache_write (cache=0xa5a778, path=0xa585c8 "/path/to/.tarsnap") at tar/ccache/ccache_write.c:262
#15 0x004da017 in tarsnap_mode_c (bsdtar=0x537d20 <bsdtar_storage>) at tar/write.c:326
#16 0x004c154e in main (argc=<optimized out>, argv=<optimized out>) at tar/bsdtar.c:1145
#17 0xb7a91286 in __libc_start_main (main=0x4bfa80 <main>, argc=0xb, argv=0xbf86f944, init=0x50bf10 <__libc_csu_init>, fini=0x50bf70 <__libc_csu_fini>, rtld_fini=0xb7efaf50 <_dl_fini>,
stack_end=0xbf86f93c) at ../csu/libc-start.c:291
#18 0x004c18c7 in _start ()
from tarsnap.
@0xkag oops, sorry. I only checked my fix for --list-archives
, and I just assumed it would work with -c
as well. My apologies.
I've been digging into this, and it's trickier than I thought at first. Please switch back to 1.0.39, and I'll update this issue when I have a definite, well-tested, well-reasoned fix.
(I'm seeing these problems as well, on both Ubuntu trusty 14.04 and Debian 10.3 buster, so future action from you shouldn't be needed until we have an official fix.)
from tarsnap.
@gperciva This is fixed now, right?
from tarsnap.
Yes, in #380.
from tarsnap.
Related Issues (20)
- tarsnap: Pathname in pax header can't be converted to current locale. HOT 9
- Misleading tarsnap error on negative account balance HOT 5
- Workaround for Windows Subsystem for Linux bug with link() HOT 1
- Add support for .gitignore files HOT 2
- escaping bug/typo in tarsnap(1) manpage HOT 1
- Machine name doesn't work with accents ? HOT 5
- master fails to build on old gcc (below version 9) HOT 9
- apt-key is deprecated - update installation instructions HOT 5
- Tarsnap Website Screen Reader Compatibility HOT 3
- Look for tarsnap.conf in ~/.config/tarsnap/ HOT 1
- Optional support for CACHEDIR.TAG files HOT 2
- New release? HOT 2
- Build fails on NetBSD HOT 4
- build: The <sys/sysctl.h> header is deprecated
- False warnings from clang-scan
- tarsnap can be tricked into skipping file using "touch -r" HOT 5
- libressl 3.6 will add `OPENSSL_cleanup()` HOT 1
- Deleting of archives taking up a lot of server -> client bandwidth HOT 6
- workaround for libc/kernel disagreement about whether lchmod exists HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tarsnap.