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

Re: Bug#669061: apt: http method dies on sparc

On 04/18/2012 06:07 PM, David Kalnischkies wrote:
On Tue, Apr 17, 2012 at 00:22, Kurt Roeckx<kurt@roeckx.be>  wrote:
I guess you're not a DD, and so don't have access to the porter
Correct guess, but I am adventures enough to work around it:
I had a lot of fun today trying to compile apt=0.9.1 in a qemu-sparc
debian etch image from aurel32 [0]. Took ages and (surprisingly) few
changes to compile with g++-4.1 and the environment in general. :)

It seems to be indeed the way the sha256 and sha512 checksums are
calculated. To make it a bit obscure: we have a testcase checking them
and they run successfully producing the correct output.
(for reference: test/libapt/hashsums_test.cc)

The bug seems only to be triggered if a checksum is "slowly" build
as it is the case in the http transport while downloading.

To reproduce you can use:
$ cat request
601 Configuration
Config-Item: Acquire::http::DependOnSTDIN=0

600 Acquire URI
URI: http://www.debian.org/index.html
Filename: debian.index.html

$ cat request | /usr/lib/apt/methods/http
(the empty line at the end of 'request' is important!)

What you should see is a '201 URI Done' message at the
end which includes a few checksums. Instead sparc instantly
crashes after starting the download ('200 URI Start') with a
bus error.

etch's gdb is crashing on me with internal errors[2] while trying to
debug this and warns me, that it might be completely wrong about
the following, but it seems to be the case that the very first call
to SHA256_Transform in apt-pkg/contrib/sha2_internal.cc [1] fails
on line 467 (which is intended to be big endian code)
called from SHA256_Final on line 595 (=first occurrence).
[apt uses the not unrolled transform method, but the unrolled seems
to have a similar issue as it crashes, too]

SHA512 is very similar, so i presume it has the very same problem.

I'm just gessing this:
When I compile glibc some time ago I ran into problems when compiling glibc' s SHA256,
your routines look quite similar. The fix I used back then was:

diff -Naur gcc-4.4.2.ori/gcc/config/sparc/constraints.md gcc-4.4.2/gcc/config/sparc/constraints.md --- gcc-4.4.2.ori/gcc/config/sparc/constraints.md 2010-11-02 11:47:04.000000000 +0100 +++ gcc-4.4.2/gcc/config/sparc/constraints.md 2010-11-02 11:47:20.000000000 +0100
@@ -35,10 +35,10 @@+

;; In the non-V9 case, coerce V9 'e' class to 'f', so we can use 'e' in the
 ;; MD file for V8 and V9.
-(define_register_constraint "e" "TARGET_V9 ? EXTRA_FP_REGS : FP_REGS"
+(define_register_constraint "e" "(TARGET_FPU ? (TARGET_V9 ? EXTRA_FP_REGS : FP_REGS) : NO_REGS)"
  "Any floating-point register")

-(define_register_constraint "f" "FP_REGS"
+(define_register_constraint "f" "(TARGET_FPU ? FP_REGS : NO_REGS)"
  "Lower floating-point register")

(define_register_constraint "h" "(TARGET_V9 && TARGET_V8PLUS ? I64_REGS : NO_REGS)"

At that time however it was a gcc "compiler error" that I ran into. The patch above
solved my problem.
Maybe it is totally unrelated to your problem though...
-- Konrad

As i run out of time for today i am leaving these dangling pointers as
they are for now and hope someone can connect the dots. CC'ing sparc
mailinglist as they have properly a good chance to find the problem
before i manage to warp my head around it…

Best regards

David Kalnischkies

[0] http://people.debian.org/~aurel32/qemu/sparc/
[1] http://anonscm.debian.org/loggerhead/apt/debian-sid/annotate/head:/apt-pkg/contrib/sha2_internal.cc#L441
[2] internal-error: register_size: Asseration 'regnum>= 0&&  regnum<

Reply to: