Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

/usr/lib/x86_64-linux-gnu/libpthread.so: invalid ELF header #1

Closed
iamacarpet opened this issue May 3, 2019 · 9 comments

Comments

Projects
None yet
2 participants
@iamacarpet
Copy link

commented May 3, 2019

Hello @notti ,

I'm trying to test this against my SQLite3 bindings, which I've modified to add Linux support with this library and pushed to a temporary repository: https://github.com/iamacarpet/go-sqlite3-dynamic

Trying to run it, I created a new folder with main_test.go, running with CGO_ENABLED=0 go test

package sqlite3

import (
	"os"
	"testing"

	"database/sql"

	_ "github.com/iamacarpet/go-sqlite3-dynamic"

	"github.com/stretchr/testify/assert"
)

func TestXxx(t *testing.T) {
	path := "test.db"

	f, err := os.Create(path)
	if err != nil {
		t.Fatal(err)
	}
	f.Close()

	db, err := sql.Open(`sqlite3`, path)
	if err != nil {
		t.Fatal(err)
	}

	r, err := db.Exec(`CREATE TABLE test (
		id integer PRIMARY KEY NOT NULL,
		name varchar(30)
	)`)
	if err != nil {
		t.Fatal(err)
	}

	_ = r

	r, err = db.Exec(`INSERT INTO test(name) VALUES ('first') `)
	if err != nil {
		t.Fatal(err)
	}
	rowid, err := r.LastInsertId()
	if err != nil {
		t.Fatal(err)
	}
	affected, err := r.RowsAffected()
	if err != nil {
		t.Fatal(err)
	}
	assert.Equal(t, int64(1), rowid)
	assert.Equal(t, int64(1), affected)

	r, err = db.Exec(`INSERT INTO test(name) VALUES ('second') `)
	if err != nil {
		t.Fatal(err)
	}
	rowid, err = r.LastInsertId()
	if err != nil {
		t.Fatal(err)
	}
	affected, err = r.RowsAffected()
	if err != nil {
		t.Fatal(err)
	}
	assert.Equal(t, int64(2), rowid)
	assert.Equal(t, int64(1), affected)

	db.Close()
	os.Remove(`./test.db`)
}

It's throwing the error:

/tmp/go-build846919307/b001/sqlite3-test.test: error while loading shared libraries: /usr/lib/x86_64-linux-gnu/libpthread.so: invalid ELF header
exit status 127
FAIL    sqlite3-test    0.001s

On Ubuntu 18.04, /usr/lib/x86_64-linux-gnu/libpthread.so is an text file:

$ file /usr/lib/x86_64-linux-gnu/libpthread.so
/usr/lib/x86_64-linux-gnu/libpthread.so: ASCII text
$ cat /usr/lib/x86_64-linux-gnu/libpthread.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib/x86_64-linux-gnu/libpthread.so.0 /usr/lib/x86_64-linux-gnu/libpthread_nonshared.a )

I checked for references to libpthread.so in your code and found a few.

Looking here , changing libpthread.so to libpthread.so.0 did nothing.

When I changed all occurrences in this file, the error changes to a segfault.

$ CGO_ENABLED=0 go test
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x2 addr=0x7efe3f722fa8 pc=0x7efe3f50be19]

runtime stack:
runtime.throw(0x746fc8, 0x2a)
        /usr/local/go/src/runtime/panic.go:617 +0x72
runtime.sigpanic()
        /usr/local/go/src/runtime/signal_unix.go:374 +0x4a9

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x522090, 0xc0000a7d88, 0xc0000a7da8)
        /usr/local/go/src/runtime/cgocall.go:128 +0x5b fp=0xc0000a7d78 sp=0xc0000a7d40 pc=0x40418b
github.com/notti/nocgo.callWrapper(0xc000084060, 0x2a, 0x30, 0xc000000002, 0x29, 0x30, 0x7efe3f6d46d0, 0x0, 0x40b4ed, 0xc0000a7f28, ...)
        ~/go-projects/src/github.com/notti/nocgo/call_amd64.s:69 +0x49 fp=0xc0000a7da8 sp=0xc0000a7d78 pc=0x522069
github.com/notti/nocgo.Open(0x746546, 0x29, 0x40c248, 0x70, 0x71bdc0)
        ~/go-projects/src/github.com/notti/nocgo/dlopen.go:61 +0x84 fp=0xc0000a7e00 sp=0xc0000a7da8 pc=0x521114
github.com/iamacarpet/go-sqlite3-dynamic.registerLibrary()
        ~/go-projects/src/github.com/iamacarpet/go-sqlite3-dynamic/dynamic_register_linux.go:65 +0x4b fp=0xc0000a7f38 sp=0xc0000a7e00 pc=0x527bcb
github.com/iamacarpet/go-sqlite3-dynamic.init.0()
        ~/go-projects/src/github.com/iamacarpet/go-sqlite3-dynamic/sqlite3.go:23 +0x22 fp=0xc0000a7f68 sp=0xc0000a7f38 pc=0x5290e2
github.com/iamacarpet/go-sqlite3-dynamic.init()
        <autogenerated>:1 +0x93 fp=0xc0000a7f78 sp=0xc0000a7f68 pc=0x52e863
sqlite3-test.init()
        <autogenerated>:1 +0x54 fp=0xc0000a7f88 sp=0xc0000a7f78 pc=0x695954
main.init()
        <autogenerated>:1 +0x54 fp=0xc0000a7f98 sp=0xc0000a7f88 pc=0x695bf4
runtime.main()
        /usr/local/go/src/runtime/proc.go:188 +0x1c8 fp=0xc0000a7fe0 sp=0xc0000a7f98 pc=0x42ea08
runtime.goexit()
        /usr/local/go/src/runtime/asm_amd64.s:1337 +0x1 fp=0xc0000a7fe8 sp=0xc0000a7fe0 pc=0x45b481
exit status 2
FAIL    sqlite3-test    0.009s

My Go version:

$ go version
go version go1.12.4 linux/amd64

Am I doing something stupid?

Regards,
iamacarpet

@notti

This comment has been minimized.

Copy link
Owner

commented May 4, 2019

relink is from an older implementation and no longer needed.
So https://github.com/notti/nocgo/blob/master/fakecgo/symbols_linux.go is the right place and yeah it should have been libpthread.so.0.
Hmm not sure yet about the segfault; I need to investigate a bit further there.

@notti

This comment has been minimized.

Copy link
Owner

commented May 4, 2019

@iamacarpet something unrelated: You don't have to specify the full path in https://github.com/iamacarpet/go-sqlite3-dynamic/blob/3b18947cf2a96fb8845e27db717c46781ec2fb6d/dynamic_register_linux.go#L65 - "libsqlite3.so.0" is enough.
On my linux your test works - so looks like there is something else going on that's dependent on your environment. The traceback looks a bit weird (segfault on calling entersyscall?)
Can you try getting a traceback with gdb?

@iamacarpet

This comment has been minimized.

Copy link
Author

commented May 7, 2019

Thanks @notti

Back trace from gdb:

(gdb) run
Starting program: ~/go-projects/src/sqlite3-test/sqlite3-test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff53af700 (LWP 21855)]
[New Thread 0x7ffff4bae700 (LWP 21856)]
[New Thread 0x7fffeffff700 (LWP 21857)]
[New Thread 0x7fffef7fe700 (LWP 21858)]
[New Thread 0x7fffeeffd700 (LWP 21859)]
[New Thread 0x7fffee7fc700 (LWP 21860)]

Thread 1 "sqlite3-test" received signal SIGSEGV, Segmentation fault.
_dl_debug_initialize (ldbase=ldbase@entry=0, ns=-2) at dl-debug.c:57
57      dl-debug.c: No such file or directory.
(gdb) bt
#0  _dl_debug_initialize (ldbase=ldbase@entry=0, ns=-2) at dl-debug.c:57
#1  0x00007ffff7de99e4 in _dl_open (file=<optimized out>, mode=<optimized out>, caller_dlopen=0x4abbb6 <asmcall+982>, nsid=<optimized out>, argc=1, argv=<optimized out>, env=0x7fffffffe458) at dl-open.c:632
#2  0x00007ffff7bd1f96 in dlopen_doit (a=a@entry=0x7fffffffe340) at dlopen.c:66
#3  0x00007ffff77282df in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffe2e0, operate=0x7ffff7bd1f40 <dlopen_doit>, args=0x7fffffffe340) at dl-error-skeleton.c:196
#4  0x00007ffff772836f in __GI__dl_catch_error (objname=0x5dd7b0, errstring=0x5dd7b8, mallocedp=0x5dd7a8, operate=<optimized out>, args=<optimized out>) at dl-error-skeleton.c:215
#5  0x00007ffff7bd2735 in _dlerror_run (operate=operate@entry=0x7ffff7bd1f40 <dlopen_doit>, args=args@entry=0x7fffffffe340) at dlerror.c:162
#6  0x00007ffff7bd2051 in __dlopen (file=<optimized out>, mode=<optimized out>) at dlopen.c:87
#7  0x00000000004abbb6 in asmcall () at ~/go-projects/src/github.com/notti/nocgo/call_amd64.s:145
#8  0x00007ffff7f49078 in ?? ()
#9  0x00007ffff7fb3c28 in ?? ()
#10 0x00000000005bf440 in ?? ()
#11 0x00000000004545b0 in runtime.asmcgocall () at /usr/local/go/src/runtime/asm_amd64.s:635
#12 0x0000000000450ffc in runtime.(*mheap).alloc.func1 () at /usr/local/go/src/runtime/mheap.go:1048
#13 0x0000000000452dd6 in runtime.systemstack () at /usr/local/go/src/runtime/asm_amd64.s:351
#14 0x000000000042e2b0 in ?? () at /usr/local/go/src/runtime/proc.go:1082
#15 0x0000000000452c69 in runtime.rt0_go () at /usr/local/go/src/runtime/asm_amd64.s:201
#16 0x0000000000000000 in ?? ()

I guess the actual error is this: dl-debug.c: No such file or directory.

Frustrating as the file does exist:

$ ls -lh /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
lrwxrwxrwx 1 root root 19 Jan 22  2018 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 -> libsqlite3.so.0.8.6

I changed my code to remove the full path as you suggested:

lib, err := nocgo.Open("libsqlite3.so.0")

Then also tried:

lib, err := nocgo.Open("libsqlite3.so.0.8.6")

to see if maybe it just didn't want to follow the symlink, but no joy.

Tried it on an old Ubuntu 14.04 VM with Go 1.11 as well, but still the same thing.

Just out of interest, what distro/version did you test against that worked?

Regards,
iamacarpet

@iamacarpet

This comment has been minimized.

Copy link
Author

commented May 7, 2019

Ah, my mistake, that error was related to the glibc sources not being available, not the library not being found - my apologies, haven't really used gdb before.

This helped: https://stackoverflow.com/questions/36025694/loading-dl-debug-c-in-gdb-ubuntu-14-04-4-lts

(gdb) run
Starting program: ~/go-projects/src/sqlite3-test/sqlite3-test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff53af700 (LWP 22451)]
[New Thread 0x7ffff4bae700 (LWP 22452)]
[New Thread 0x7fffeffff700 (LWP 22453)]
[New Thread 0x7fffef7fe700 (LWP 22454)]
[New Thread 0x7fffeeffd700 (LWP 22455)]
[New Thread 0x7fffee7fc700 (LWP 22456)]

Thread 1 "sqlite3-test" received signal SIGSEGV, Segmentation fault.
_dl_debug_initialize (ldbase=ldbase@entry=0, ns=-2) at dl-debug.c:57
57            r->r_version = 1  /* R_DEBUG_VERSION XXX */;
(gdb) bt
#0  _dl_debug_initialize (ldbase=ldbase@entry=0, ns=-2) at dl-debug.c:57
#1  0x00007ffff7de99e4 in _dl_open (file=<optimized out>, mode=<optimized out>, caller_dlopen=0x4abbb6 <asmcall+982>, nsid=<optimized out>, argc=1, argv=<optimized out>, env=0x7fffffffe458) at dl-open.c:632
#2  0x00007ffff7bd1f96 in dlopen_doit (a=a@entry=0x7fffffffe340) at dlopen.c:66
#3  0x00007ffff77282df in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffe2e0, operate=0x7ffff7bd1f40 <dlopen_doit>, args=0x7fffffffe340) at dl-error-skeleton.c:196
#4  0x00007ffff772836f in __GI__dl_catch_error (objname=0x5dd7b0, errstring=0x5dd7b8, mallocedp=0x5dd7a8, operate=<optimized out>, args=<optimized out>) at dl-error-skeleton.c:215
#5  0x00007ffff7bd2735 in _dlerror_run (operate=operate@entry=0x7ffff7bd1f40 <dlopen_doit>, args=args@entry=0x7fffffffe340) at dlerror.c:162
#6  0x00007ffff7bd2051 in __dlopen (file=<optimized out>, mode=<optimized out>) at dlopen.c:87
#7  0x00000000004abbb6 in asmcall () at ~/go-projects/src/github.com/notti/nocgo/call_amd64.s:145
#8  0x00007ffff7f49078 in ?? ()
#9  0x00007ffff7fb3c28 in ?? ()
#10 0x00000000005bf440 in ?? ()
#11 0x00000000004545b0 in runtime.asmcgocall () at /usr/local/go/src/runtime/asm_amd64.s:635
#12 0x0000000000450ffc in runtime.(*mheap).alloc.func1 () at /usr/local/go/src/runtime/mheap.go:1048
#13 0x0000000000452dd6 in runtime.systemstack () at /usr/local/go/src/runtime/asm_amd64.s:351
#14 0x000000000042e2b0 in ?? () at /usr/local/go/src/runtime/proc.go:1082
#15 0x0000000000452c69 in runtime.rt0_go () at /usr/local/go/src/runtime/asm_amd64.s:201
#16 0x0000000000000000 in ?? ()

Although that appears to make less sense to me now - hope it means something to you!

Regards,
iamacarpet

@notti

This comment has been minimized.

Copy link
Owner

commented May 7, 2019

Thanks for the backtrace. This makes a bit more sense now (although I think I need a bit more debugging). What we're seeing here is that calling dlopen works but it crashes then somewhere inside glibc.
Sadly it looks like I need to try to replicate this in a virtual machine or something - this will take a couple of days.

@notti

This comment has been minimized.

Copy link
Owner

commented May 9, 2019

I could reproduce it. So now for the hard part: fixing it.

notti added a commit that referenced this issue May 9, 2019

@notti

This comment has been minimized.

Copy link
Owner

commented May 9, 2019

@iamacarpet Latest master should fix the issues - can you test if it works for you?

@iamacarpet

This comment has been minimized.

Copy link
Author

commented May 10, 2019

Thanks @notti ,

Just given this a try, runs without a stacktrace now, so that's great :).

It's throwing me a "SQL Logic Error" now, which I don't get on Windows running against the DLL, so will spend some time debugging.

@iamacarpet

This comment has been minimized.

Copy link
Author

commented May 15, 2019

All sorted, thanks again for all the help!

@iamacarpet iamacarpet closed this May 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.