[gambit-list] ___setup memory corruption(?) on iPhone
k.zorin at me.com
Fri Jun 8 12:21:17 EDT 2012
> I saw similar problems using 4.6.6 built for iOS with clang (Xcode 4.3.2). Unfortunately, I can't tell you much about the errors. They were segfaults that occurred at random (short) intervals after the call to setup, and that's about all I know. Commenting out the call to setup (and, naturally, anything that depended on it) cured the segfault.
> The built apps crashed hard and left no information behind. In fact, the only evidence that they had occurred at all (besides the quick disappearance of the app form the device screen) was a single line each time in the console log reporting a segfault.
> One other thing I can report is that I had NSLog statements in code after the segfaults for testing and debugging, and some of those ran sometimes before the segfault. They printed the results of calls into the Gambit runtime, so we can infer that Gambit setup managed to build enough of the Gambit environment to carry out some evaluations before hitting whatever broken part caused the segfault.
The clang build-related problem I mentioned was due to some "crt" file missing; it was solved by following another ML post's advice and running "sudo ln -s crt1.3.1.o crt1.10.6.o" in the same directory where crt1.3.1.o can be found. This allowed me to use build-gambit-iOS(.sh) with clang(++) as the compiler.
I stayed up pretty late last night trying to figure out what could possibly be the problem with ___setup(). My thinking is that if it's some "deep" issue in ___setup(), we would have seen it happen somewhere else, at least once, but I haven't been able to find any reports on this that weren't eventually identified as "user error". For comparison I've never had a single issue with this on x86_64 or i386, same program, same everything. So it's probably not ___setup(), at least not directly. If it's an ARM-related problem (miscompilation et. al.), we would have seen this issue with other programs as well, but again, reports of ARM architecture-related crashes/weirdness are pretty rare and usually affect programs in a much deeper sense than simply "calling one function and getting a crash" vs. "not calling it and everything else is fine forever".
I did notice that my iOS gambit program ran fine (i.e. calling ___setup() had no unexpected effects) whenever I ran it without having attached the Xcode debugger first. That is, if I start it "normally" by thumbing the app icon on the phone, it runs perfectly fine as expected, exactly like on other platforms. Whenever I ran it with the Xcode debugger attached (by hitting "Run" in Xcode), all sorts of bizarre things would happen once ___setup() returned, as described.
Is it possible that something that Gambit does to the process' state interferes with Apple's iOS debugger, and/or is there some assumption made by ___setup() about initial process state that's invalidated by something the Xcode debugger does? Or am I barking up the wrong tree here altogether?
More information about the Gambit-list