tus / tusd

Reference server implementation in Go of tus: the open protocol for resumable file uploads
https://tus.github.io/tusd
MIT License
3.04k stars 475 forks source link

Error when running the latest release on debian 5 386 #1052

Closed algsupport closed 8 months ago

algsupport commented 9 months ago

Describe the bug I have downloaded the latest linux 386 server release and ran it on a debian 5 32bit version. I used the python client implementation example to try to upload a file.

While testing I got the below error:

2023/12/22 11:58:54.979436 level=INFO event="http: panic serving 127.0.0.1:49969: unaligned 64-bit atomic operation
goroutine 82 [running]:
net/http.(*conn).serve.func1()
    net/http/server.go:1868 +0xe0
panic({0x8c538e0, 0x8f80608})
    runtime/panic.go:920 +0x24c
runtime/internal/atomic.panicUnaligned()
    runtime/internal/atomic/unaligned.go:8 +0x2d
runtime/internal/atomic.Xadd64(0xa43bd74, 0x3e8)
    runtime/internal/atomic/atomic_386.s:125 +0x11
github.com/tus/tusd/v2/pkg/handler.(*bodyReader).Read(0xa43bd60, {0xa75e000, 0x8000, 0x8000})
    github.com/tus/tusd/v2/pkg/handler/body_reader.go:43 +0x9a
io.copyBuffer({0x8f811ac, 0xa446d78}, {0x8f81314, 0xa43bd60}, {0x0, 0x0, 0x0})
    io/io.go:430 +0x1bf
io.Copy(...)
    io/io.go:389
os.genericReadFrom(0xa446d78, {0x8f81314, 0xa43bd60})
    os/file.go:161 +0x53
os.(*File).ReadFrom(0xa446d78, {0x8f81314, 0xa43bd60})
    os/file.go:155 +0xda
io.copyBuffer({0x8f80f40, 0xa446d78}, {0x8f81314, 0xa43bd60}, {0x0, 0x0, 0x0})
    io/io.go:416 +0x127
io.Copy(...)
    io/io.go:389
github.com/tus/tusd/v2/pkg/filestore.(*fileUpload).WriteChunk(0xa498910, {0x8f8c5e0, 0xa622300}, 0x0, {0x8f81314, 0xa43bd60})
    github.com/tus/tusd/v2/pkg/filestore/filestore.go:165 +0x90
github.com/tus/tusd/v2/pkg/handler.(*UnroutedHandler).writeChunk(0xa6fc000, 0xa622300, {0xcc, {0x0, 0x0}, 0xa43bd40}, {0x8f8c5a0, 0xa498910}, {{0xa6f20c0, 0x20}, ...})
    github.com/tus/tusd/v2/pkg/handler/unrouted_handler.go:874 +0x4d9
github.com/tus/tusd/v2/pkg/handler.(*UnroutedHandler).PatchFile(0xa6fc000, {0x8f8bc88, 0xa4cc280}, 0xa4aab00)
    github.com/tus/tusd/v2/pkg/handler/unrouted_handler.go:770 +0x8b9
net/http.HandlerFunc.ServeHTTP(0xa61f2c8, {0x8f8bc88, 0xa4cc280}, 0xa4aab00)
    net/http/server.go:2136 +0x34
github.com/bmizerany/pat.(*PatternServeMux).ServeHTTP(0xa60b4c0, {0x8f8bc88, 0xa4cc280}, 0xa4aab00)
    github.com/bmizerany/pat@v0.0.0-20170815010413-6226ea591a40/mux.go:117 +0x172
github.com/tus/tusd/v2/pkg/handler.NewHandler.(*UnroutedHandler).Middleware.func1({0x8f8bc88, 0xa4cc280}, 0xa4aaa80)
    github.com/tus/tusd/v2/pkg/handler/unrouted_handler.go:252 +0x943
net/http.HandlerFunc.ServeHTTP(0xa60b4d0, {0x8f8bc88, 0xa4cc280}, 0xa4aaa80)
    net/http/server.go:2136 +0x34
github.com/tus/tusd/v2/cmd/tusd/cli.Serve.StripPrefix.func9({0x8f8bc88, 0xa4cc280}, 0xa4aaa00)
    net/http/server.go:2179 +0x20b
net/http.HandlerFunc.ServeHTTP(0xa621398, {0x8f8bc88, 0xa4cc280}, 0xa4aaa00)
    net/http/server.go:2136 +0x34
net/http.(*ServeMux).ServeHTTP(0xa622cf0, {0x8f8bc88, 0xa4cc280}, 0xa4aaa00)
    net/http/server.go:2514 +0x15e
net/http.serverHandler.ServeHTTP({0xa6fc0a0}, {0x8f8bc88, 0xa4cc280}, 0xa4aaa00)
    net/http/server.go:2938 +0x99
net/http.(*conn).serve(0xa5ec0c0, {0x8f8c480, 0xa7aa000})
    net/http/server.go:2009 +0x66d
created by net/http.(*Server).Serve in goroutine 1
    net/http/server.go:3086 +0x47f"

Setup details Please provide following details, if applicable to your situation:

Acconut commented 9 months ago

Can you test the latest commit from the main branch? It already includes a recent commit that addresses the issue: https://github.com/tus/tusd/commit/7f7d9b029dba8489b460f2bbd9a23ce4881e6a71

algsupport commented 9 months ago

Hello, Thank you for your quick response. Since I don't have much GO experience, is it possible to create a pre-release so I can download it?

algsupport commented 9 months ago

In the end I found a way to compile the code from the main branch and it seems to be working.

Acconut commented 8 months ago

Glad you found a way. I also released v2.2.2 now, which includes the fix: https://github.com/tus/tusd/releases/tag/v2.2.2

algsupport commented 8 months ago

I revisited this project and after downloading the latest release, I am now getting this error: (My own previously compiled binary works without any issues.)

Same server different binaries.

./tusd -upload-dir=./data -port 9091

runtime: epollcreate failed with 38
fatal error: runtime: netpollinit failed

goroutine 1 [running, locked to thread]:
runtime.throw({0x8df5a37, 0x1b})
        runtime/panic.go:1077 +0x4d fp=0xa120cb0 sp=0xa120c9c pc=0x808752d
runtime.netpollinit()
        runtime/netpoll_epoll.go:28 +0x20b fp=0xa120cfc sp=0xa120cb0 pc=0x8082f0b
runtime.netpollGenericInit()
        runtime/netpoll.go:216 +0x56 fp=0xa120d08 sp=0xa120cfc pc=0x8082376
internal/poll.runtime_pollServerInit()
        runtime/netpoll.go:208 +0x17 fp=0xa120d0c sp=0xa120d08 pc=0x80b9aa7
sync.(*Once).doSlow(0x96d3cb0, 0x8e2ecf8)
        sync/once.go:74 +0xb3 fp=0xa120d34 sp=0xa120d0c pc=0x80c8b23
sync.(*Once).Do(0x96d3cb0, 0x8e2ecf8)
        sync/once.go:65 +0x3f fp=0xa120d40 sp=0xa120d34 pc=0x80c8a5f
internal/poll.(*pollDesc).init(0xa12a0d8, 0xa12a0c0)
        internal/poll/fd_poll_runtime.go:39 +0x31 fp=0xa120d50 sp=0xa120d40 pc=0x812eb81
internal/poll.(*FD).Init(0xa12a0c0, {0x8dda7a8, 0x4}, 0x1)
        internal/poll/fd_unix.go:65 +0x4c fp=0xa120d64 sp=0xa120d50 pc=0x812f7bc
os.newFile(0x3, {0xa040048, 0x11}, 0x1)
        os/file_unix.go:233 +0x14d fp=0xa120d88 sp=0xa120d64 pc=0x813c26d
os.openFileNolog({0xa040048, 0x11}, 0x0, 0x0)
        os/file_unix.go:301 +0x187 fp=0xa120db8 sp=0xa120d88 pc=0x813c477
os.OpenFile({0xa040048, 0x11}, 0x0, 0x0)
        os/file.go:334 +0x51 fp=0xa120dd8 sp=0xa120db8 pc=0x813a8f1
os.Open(...)
        os/file.go:314
google.golang.org/protobuf/internal/detrand.binaryHash()
        google.golang.org/protobuf@v1.31.0/internal/detrand/rand.go:46 +0x6f fp=0xa120e6c sp=0xa120dd8 pc=0x84a025f
google.golang.org/protobuf/internal/detrand.init()
        google.golang.org/protobuf@v1.31.0/internal/detrand/rand.go:38 +0x1a fp=0xa120e78 sp=0xa120e6c pc=0x84a058a
runtime.doInit1(0x9656e20)
        runtime/proc.go:6740 +0xd6 fp=0xa120fa4 sp=0xa120e78 pc=0x8098076
runtime.doInit(...)
        runtime/proc.go:6707
runtime.main()
        runtime/proc.go:249 +0x3b8 fp=0xa120ff0 sp=0xa120fa4 pc=0x808a3f8
runtime.goexit()
        runtime/asm_386.s:1363 +0x1 fp=0xa120ff4 sp=0xa120ff0 pc=0x80be5f1

goroutine 2 [force gc (idle)]:
runtime.gopark(0x8e2eb74, 0x96beec0, 0x11, 0x14, 0x1)
        runtime/proc.go:398 +0x10c fp=0xa052fdc sp=0xa052fc8 pc=0x808a7ec
runtime.goparkunlock(...)
        runtime/proc.go:404
runtime.forcegchelper()
        runtime/proc.go:322 +0xd3 fp=0xa052ff0 sp=0xa052fdc pc=0x808a613
runtime.goexit()
        runtime/asm_386.s:1363 +0x1 fp=0xa052ff4 sp=0xa052ff0 pc=0x80be5f1
created by runtime.init.5 in goroutine 1
        runtime/proc.go:310 +0x23

goroutine 17 [GC sweep wait]:
runtime.gopark(0x8e2eb74, 0x96bfca0, 0xc, 0x14, 0x1)
        runtime/proc.go:398 +0x10c fp=0xa04e7cc sp=0xa04e7b8 pc=0x808a7ec
runtime.goparkunlock(...)
        runtime/proc.go:404
runtime.bgsweep(0xa08c000)
        runtime/mgcsweep.go:280 +0x9b fp=0xa04e7e8 sp=0xa04e7cc pc=0x80729eb
runtime.gcenable.func1()
        runtime/mgc.go:200 +0x27 fp=0xa04e7f0 sp=0xa04e7e8 pc=0x8064867
runtime.goexit()
        runtime/asm_386.s:1363 +0x1 fp=0xa04e7f4 sp=0xa04e7f0 pc=0x80be5f1
created by runtime.gcenable in goroutine 1
        runtime/mgc.go:200 +0x77

goroutine 18 [GC scavenge wait]:
runtime.gopark(0x8e2eb74, 0x96c01c0, 0xd, 0x14, 0x2)
        runtime/proc.go:398 +0x10c fp=0xa04efb8 sp=0xa04efa4 pc=0x808a7ec
runtime.goparkunlock(...)
        runtime/proc.go:404
runtime.(*scavengerState).park(0x96c01c0)
        runtime/mgcscavenge.go:425 +0x60 fp=0xa04efcc sp=0xa04efb8 pc=0x806fd70
runtime.bgscavenge(0xa08c000)
        runtime/mgcscavenge.go:653 +0x4b fp=0xa04efe8 sp=0xa04efcc pc=0x80703eb
runtime.gcenable.func2()
        runtime/mgc.go:201 +0x27 fp=0xa04eff0 sp=0xa04efe8 pc=0x8064827
runtime.goexit()
        runtime/asm_386.s:1363 +0x1 fp=0xa04eff4 sp=0xa04eff0 pc=0x80be5f1
created by runtime.gcenable in goroutine 1
        runtime/mgc.go:201 +0xb7

goroutine 3 [finalizer wait]:
runtime.gopark(0x8e2ea10, 0x96d3850, 0x10, 0x14, 0x1)
        runtime/proc.go:398 +0x10c fp=0xa052798 sp=0xa052784 pc=0x808a7ec
runtime.runfinq()
        runtime/mfinal.go:193 +0xfc fp=0xa0527f0 sp=0xa052798 pc=0x806395c
runtime.goexit()
        runtime/asm_386.s:1363 +0x1 fp=0xa0527f4 sp=0xa0527f0 pc=0x80be5f1
created by runtime.createfing in goroutine 1
        runtime/mfinal.go:163 +0x60
algsupport commented 8 months ago

You can ignore my previous message. The specific server has a kernel version that is not supported by golang. I also tried with the nodejs implementation but wasn't able to make it work.