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

segmentation fault #2

Open
michaljirman opened this issue May 13, 2021 · 2 comments
Open

segmentation fault #2

michaljirman opened this issue May 13, 2021 · 2 comments

Comments

@michaljirman
Copy link

michaljirman commented May 13, 2021

Hi @awgh,
just trying the darwin_example with a dylib on Mac OS (x86_64) but experiencing segmentation fault. I assume this is due to SIP being enabled. Is this working for you with the SIP being enabled, please?

Found image at 0x01000000
Found image at 0x02b71000
found NSCreateObjectFileImageFromMemory
found NSLinkModule
Found dyld!
unexpected fault address 0xb01dfacedebac1e
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0xb01dfacedebac1e pc=0x2b80432]

goroutine 1 [running]:
runtime.throw(0x10f0048, 0x5)
	/usr/local/opt/go/libexec/src/runtime/panic.go:1117 +0x72 fp=0xc000092bb0 sp=0xc000092b80 pc=0x10328b2
runtime: unexpected return pc for runtime.sigpanic called from 0x2b80432
stack: frame={sp:0xc000092bb0, fp:0xc000092be8} stack=[0xc000092000,0xc000093000)
000000c000092ab0:  000000c000092b00  000000c000000001
000000c000092ac0:  000000000119c020  000000c000092af0
000000c000092ad0:  0000000001050779 <runtime.write1+57>  0000000001065d00 <runtime.write_trampoline+0>
000000c000092ae0:  000000c000092b00  0000000000000001
000000c000092af0:  000000c000092b30  0000000001034225 <runtime.gwrite+165>
000000c000092b00:  0000000000000002  00000000010f8710
000000c000092b10:  0000000000000001  0000000000000001
000000c000092b20:  000000c000092b8f  0000000000000011
000000c000092b30:  000000c000092b80  0000000001034b18 <runtime.printstring+120>
000000c000092b40:  0000000001032a97 <runtime.fatalthrow+87>  000000c000092b50
000000c000092b50:  000000000105e4e0 <runtime.fatalthrow.func1+0>  000000c000000180
000000c000092b60:  00000000010328b2 <runtime.throw+114>  000000c000092b80
000000c000092b70:  000000c000092ba0  00000000010328b2 <runtime.throw+114>
000000c000092b80:  000000c000092b88  000000000105e440 <runtime.throw.func1+0>
000000c000092b90:  00000000010f0048  0000000000000005
000000c000092ba0:  000000c000092bd8  0000000001047716 <runtime.sigpanic+630>
000000c000092bb0: <00000000010f0048  0000000000000005
000000c000092bc0:  0000000001305ae0  0b01dfacedebac1e
000000c000092bd0:  000000c000000180  000000c000092c28
000000c000092be0: !0000000002b80432 >00000000012cf000
000000c000092bf0:  000000c000092e80  0000000000000000
000000c000092c00:  0000000001305ae0  0000000002b8035f
000000c000092c10:  00000000000000f9  00000000010f86f8
000000c000092c20:  0000000000000039  000000c000092c80
000000c000092c30:  00000000010c1b76 <github.com/awgh/cppgo/asmcall/cdecl.call3+22>  00000000010c195e <github.com/awgh/cppgo/asmcall/cdecl.Call+286>
000000c000092c40:  0000000002b8035f  0000000001305ae0
000000c000092c50:  000000c000092e80  000000c000092cf8
000000c000092c60:  0000000000000001  000000c00009d1e0
000000c000092c70:  0000000000000000  0000000000000000
000000c000092c80:  000000c000092e70  00000000010c266e <github.com/Binject/universal.LoadLibraryImpl+1454>
000000c000092c90:  0000000002b8035f  000000c000092d88
000000c000092ca0:  0000000000000003  0000000000000003
000000c000092cb0:  0000000000000001  0000000000000000
000000c000092cc0:  0000000000000000  0000000000000000
000000c000092cd0:  0000000000000000  0000000000000000
000000c000092ce0:  0101010000000003
runtime.sigpanic()
	/usr/local/opt/go/libexec/src/runtime/signal_unix.go:741 +0x276 fp=0xc000092be8 sp=0xc000092bb0 pc=0x1047716
exit status 2```
@awgh
Copy link
Member

awgh commented May 14, 2021

Nope, SIP does not affect this.

The problem is that I never checked in an OSX test library for the x86_64 platform! In the test/64 folder, there is only a dylib for arm64: "main-arm64.dyld" and the darwin-example is hardcoded to load the arm64 dylib.

I will leave this issue open to remind me to fix this, but in the meantime, all you have to do is compile the test library code in the test folder yourself on your x86_64 machine and point darwin-example at your new dylib.

The source code for the test library is here:
https://github.com/Binject/universal/tree/main/test/src/main_dll

The build commands are in build.bat in that folder (should work if you source it as a shell script too, just gcc commands).

I apologize for the oversight, but I don't actually have an x86_64 Mac at the moment, only the M1. We did test this on OSX x86_64, but it was a loaner and I didn't save the dylib.

Let me know if that works for you or if it doesn't!

Cheers

@michaljirman
Copy link
Author

michaljirman commented May 14, 2021

Thanks for getting back to me so quick. Actually i am trying the library compiled in the way as you described. I will also try it on separate arm device soon. For the Mac I guess I will need to take time understand your code and then get in debugger.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants