runtime: _rt0_arm_darwin_lib smashes R11 in darwin/arm c-archive entry point #12590
Comments
|
What are the go tool version, and the gomobile version used in your computer, and your coworker's computer? go version |
|
go version go1.5 darwin/amd64 Co worker does not use go, so I am building the library and then adding it to a shared xcode project. When I build the project its fine and runs on the device. When he builds the project it gives the PIE error and crashes immediately. Also tried building like this to address PIE error: but it didn't seem to make a difference. I'm not sure if that is the correct way. |
|
A little more info: All I'm doing is building the library and then adding it to the link binary with libraries phase. I'm not embedding the framework because I get an error while codesigning error: So that is probably the issue. However, the PIE problem could be an issue down the road if we try to submit to Apple. |
|
We need to know which clang you use and which SDK you are targeting to in order to reproduce. Could you paste the output of the following commands? |
|
Could you also run the |
|
Does the build process install the library on the local machine? Maybe since I'm building the framework on my machine, my Xcode has access to the library, but when my colleague builds, he doesn't have the library installed since he doesn't have golang or any of the other build files. He just has the .framework file. Does that sound like a possibility? |
Can you send us any stack traces you can gather from the crash time? There is a possibility that the framework bundle is not properly linked against the app your are building and the app is crashing to the missing symbols. Can you double check the Xcode build steps to see if the framework is included? |
|
I will check with the guy whose machine is crashing and will know tomorrow (unfortunately we're in different countries so it makes debugging all the more fun). Just to clarify: Is it sufficient to just include the framework in the 'Link Binary with Libraries' phase, without having to also embed it in the bundle? Traditionally frameworks get linked and then embedded, but on my machine it works without embedding so I'm hoping that is the case. |
|
You don't have to embed, you need to link. Embedding allows you to distribute the framework as it is in the app bundle whereas linking is statically linking the library to the final binary. |
|
Here is the stack trace of the memory error that my colleague receives when running the application on his device. Please note, he is able to run in simulator fine. So the library must be linking to some extent. But then on the device we get this. On my device it works fine. We're both running ios 8.4.1, but I'm on an iPhone 6 and he's on an iPhone 5. I've found some similar stack overflow issues: It seems this stack trace just indicates that something is going wrong when loading an external library, so it might not be of much help. However, I feel that the warning I referred to, to start this issue is relevant. It seems gomobile isn't building Position-Independent code which is required for ios apps. Whether that is what is causing the crash or not, it should be addressed. |
|
Another piece of the puzzle: he's compiling with -arch armv7 |
|
I've verified that this is armv7 specific since it works on my own iphone6 but crashes and has multiple warnings for iphone 5: Warning 1: Warning 2: Crash comes at: which based on some other questions seems to be related static initializers, but I don't know about that. the dump from gomobile bind -target=ios -x |
|
Thank you very much for all the hard work. FYI, I filed #12604 and we will fix the problem. I don't have iphone5 device. When using the iphone5 simulator & framework, I couldn't reproduce the first warning. Is the crash reproducible with iphone5? Since your build set up is different, I want to check if that's the build set up difference, or simulator vs. real device. It's a static framework, and xcode error message about dylib looks suspicious. BTW, the PIE warning didn't stop us from our Ivy app release. But our Ivy app release was done before we decide to let gomobile bind generate frameworks. :-( |
|
Hi @hyangah, I was able to get rid of the dylib warning by linking against the archive itself (within the .framework folder) rather than the framework. If you attempt to add a framework, the path gets added to xcode's framework search paths which I guess it assumes are dynamic.. which causes the dylib warning. Don't think that was contributing to the crash. I linked directly against the static library and it went away. The crash is 100% reproducible on iphone5. If I remove the library linkage app runs fine, if I add it in it gets the crash at the below mentioned area. I appreciate the help. |
|
Has anyone been able to compile a library for armv7/iphone5 (actual device, not simulator)? Just wondering if I should keep looking into fixes for this or if its some bug deeper in. I'd be happy to do tests on my iphone5 to verify. |
|
This definitely worked at some point recently, when we shipped the first version of Ivy the armv7 .a file worked. It looks like you're using the released version of Go 1.5, is that correct? I have a device here we can try it on (an armv7 iPad). I'll give it a go in the next couple of days. It looks like from your stack trace that the program is failing very early in the runtime initialization. However just to be sure, you may want to try compiling with -tags=lldb, which will enable a signal handler that may provide more information. |
|
Will do, I will also try to just build the example project as a base test. |
|
Hi @crawshaw, @hyangah @rakyll , I found the root of the crash! It seems to be triggered by any publicly declared interface. I came up with the most minimal test below (which causes a crash): If I change the interface to a struct, no crash. So please be aware of this issue and see if you can push a fix through. I am able to change my code to simply not use interfaces and will just use structs. |
|
Great detective work @scisci. Without a machine to test, I see two ways this could happen. The first and most likely is that the global constructor The second possibility is that I believe capturing blocks are saved to stack memory, and only heap allocated on request. I wrote a speculative cl/14549, and will test it out tomorrow. |
|
CL https://golang.org/cl/14549 mentions this issue. |
A framework generated with gomobile bind -target=ios has two global constructors: one initializing a data structure and another using it. These constructors are defined in different translation units, which (I believe, reasoning from C++ global constructors) means their order of initialization is undefined. A capturing block is stack allocated. Its memory is invalid after the function returns. Make a copy of the interface initializer blocks so they can be saved to the heap. Block implementation background: http://www.cocoawithlove.com/2009/10/how-blocks-are-implemented-and.html Updates golang/go#12590 Change-Id: Ia7ae9f4bbd8df6e6e79949de54b3e6c48148c700 Reviewed-on: https://go-review.googlesource.com/14549 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
crawshaw
changed the title
|
CL https://golang.org/cl/14603 mentions this issue. |
|
hi @crawshaw. What would I need to do to be able to test this? Would I have to update Go to tip, or gomobile? |
|
@scisci, you need to update Go to the tip. |
rsc
changed the title
|
CL https://golang.org/cl/16968 mentions this issue. |
The _rt0_arm_darwin_lib entrypoint has to conform to the darwin ARMv7 calling convention, which requires functions to preserve the value of R11. Go uses R11 as the liblink REGTMP register, so save it manually. Also avoid using R4, which is also callee-save. Fixes #12590 Change-Id: I9c3b374e330f81ff8fc9c01fa20505a33ddcf39a Reviewed-on: https://go-review.googlesource.com/14603 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-on: https://go-review.googlesource.com/16968 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Russ Cox <rsc@golang.org>
|
CL https://golang.org/cl/20621 mentions this issue. |
CL 14603 attempted to preserve the callee-save registers for the darwin/arm runtime initialization routine, but I believe it wasn't sufficient and resulted in the crash reported in issue Saving and restoring the registers on the stack the same way linux/arm does seems more obvious and fixes #14778, so do that. Even though #14778 is not reproducible on darwin/arm64, I applied a similar change there, and to linux/arm64 which obeys the same calling convention. Finally, this CL is a candidate for a 1.6 minor release for the same reason CL 14603 was in a 1.5 minor release (as CL 16968). It is small and only touches the iOS platforms and gomobile on darwin/arm is currently useless without it. Fixes #14778 Fixes #12590 (again) Change-Id: I7401daf0bbd7c579a7e84761384a7b763651752a Reviewed-on: https://go-review.googlesource.com/20621 Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: Elias Naur <elias.naur@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
|
CL https://golang.org/cl/22049 mentions this issue. |
CL 14603 attempted to preserve the callee-save registers for the darwin/arm runtime initialization routine, but I believe it wasn't sufficient and resulted in the crash reported in issue Saving and restoring the registers on the stack the same way linux/arm does seems more obvious and fixes #14778, so do that. Even though #14778 is not reproducible on darwin/arm64, I applied a similar change there, and to linux/arm64 which obeys the same calling convention. Finally, this CL is a candidate for a 1.6 minor release for the same reason CL 14603 was in a 1.5 minor release (as CL 16968). It is small and only touches the iOS platforms and gomobile on darwin/arm is currently useless without it. Fixes #14778 Fixes #12590 (again) Change-Id: I7401daf0bbd7c579a7e84761384a7b763651752a Reviewed-on: https://go-review.googlesource.com/20621 Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: Elias Naur <elias.naur@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-on: https://go-review.googlesource.com/22049
I've built an ios library. On one developers computer it works fine (mine where I built the library), on another developers build I get this error:
ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in main.init from /Users/... To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pieAnd then it crashes immediately.
The text was updated successfully, but these errors were encountered: