* Daniel Leidert <[email protected]> [090222 02:20]:
> There is something seriously broken. I can easily reproduce the
> segmentation fault. I simply removed db/ pool/ dists/ to start with a
> clean directory. I ran the export and createsymlinks options and then
>
> reprepro -VVV --ignore=wrongdistribution -C test include sid \
> [..].changes
>
> creashes with a segmentation fault. A first backtrace is attached. I
> needed to compile libarchive1 with debugging symbols.
>
> Can you reproduce the problem?
Yes. The important part is having Contents-file creation activated.
(As it happens when reading the list of files in the .deb file).
> #2 0xb7eb90fc in __archive_read_skip (a=0x9971c68, request=5632) at
> libarchive/archive_read.c:1009
> bytes_skipped = 1024
> total_bytes_skipped = 1024
> min = 1024
> #3 0xb7ec503d in archive_read_format_tar_skip (a=0x9971c68) at
> libarchive/archive_read_support_format_tar.c:521
> bytes_skipped = -5193991323412506872
> tar = (struct tar *) 0x9973b30
> #4 0xb7eb83a9 in archive_read_data_skip (_a=0x9971c68) at
> libarchive/archive_read.c:532
> a = (struct archive_read *) 0x9971c68
> r = 5
> buff = (const void *) 0x0
> size = 1
> offset = 129009018072
Those numbers look strange. I'll investigate if this is a reprepro or
libarchive bug.
> Is this intentional, that the files are left in the pool?
When being terminated by a segfault, cleaning up is not really something
that can be reasonably done.
> Error 17 creating
> '/srv/archive/pool/test/m/mopac7/libmopac7-1gf_1.14-2_i386.deb': File
> exists
That looks like a bug, though. Reprepro should just delete unexpected
files in the pool. (As apt-methods are setup to download there too while
upgrading, and there is no control about what they do.
> JFTR: Downgrading libarchive1 to version to 2.4.17-2 helped.
Thanks for all your work in tracking that down,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
