Hi all,
I've built (a slow version of) Gambit with llvm-gcc 4.2 on Mac OS X, targeted for the iPhone, using the build-gambit-iOS script, for the iOS 5.1 SDK. (I can't build it with latest clang, because for whatever reason Gambit's configure exits with various autoconf-related errors when clang is used.)
When I run ___setup(...) as required, from a separate thread, the function never returns. If I call it from the main thread it returns, except that after that, various Apple libraries begin to crash in mysterious ways.
If I don't run ___setup(...) at all (from any thread), everything works fine. (Except, of course, that I can't run Scheme code =))
Any ideas what could be at fault here (i.e. what I'm doing wrong)? For comparison, the same scenario (exactly the same code, linkage, etc.) built for Mac OS X works as required regardless of what thread ___setup() is called from initially.
Thanks.
Afficher les réponses par date
On Jun 6, 2012, at 5:57 PM, Kirill Zorin wrote:
Hi all,
I've built (a slow version of) Gambit with llvm-gcc 4.2 on Mac OS X, targeted for the iPhone, using the build-gambit-iOS script, for the iOS 5.1 SDK. (I can't build it with latest clang, because for whatever reason Gambit's configure exits with various autoconf-related errors when clang is used.)
When I run ___setup(...) as required, from a separate thread, the function never returns. If I call it from the main thread it returns, except that after that, various Apple libraries begin to crash in mysterious ways.
If I don't run ___setup(...) at all (from any thread), everything works fine. (Except, of course, that I can't run Scheme code =))
Any ideas what could be at fault here (i.e. what I'm doing wrong)? For comparison, the same scenario (exactly the same code, linkage, etc.) built for Mac OS X works as required regardless of what thread ___setup() is called from initially.
For what it's worth, I saw similar problems using Gambit 4.6.1. We rolled back to a 4.6.1-based toolchain for our iOS work.
On Jun 6, 2012, at 7:14 PM, Kirill Zorin wrote:
Thanks Mikel! Is there a typo in the below?
On 2012-06-06, at 7:59 PM, mikel evins wrote:
using Gambit 4.6.1. We rolled back to a 4.6.1-based
Yep; good catch. I saw the crashing problem with Gambit 4.6.6. We rolled back to 4.6.1.
As you described, after executing setup, our iOS builds would segfault at some random time later. Like yours, our build was done with clang (the most recent Xcode provides only llvm-based compilers).
Is there any particular reason for using 4.6.1 (versus some other minor revision)? Was 4.6.1 found to be the latest iOS-stable version (by git-bisect or similar)?
Thanks again.
On 2012-06-06, at 8:17 PM, mikel evins wrote:
On Jun 6, 2012, at 7:14 PM, Kirill Zorin wrote:
Thanks Mikel! Is there a typo in the below?
On 2012-06-06, at 7:59 PM, mikel evins wrote:
using Gambit 4.6.1. We rolled back to a 4.6.1-based
Yep; good catch. I saw the crashing problem with Gambit 4.6.6. We rolled back to 4.6.1.
As you described, after executing setup, our iOS builds would segfault at some random time later. Like yours, our build was done with clang (the most recent Xcode provides only llvm-based compilers).
On Jun 6, 2012, at 7:41 PM, Kirill Zorin wrote:
Is there any particular reason for using 4.6.1 (versus some other minor revision)? Was 4.6.1 found to be the latest iOS-stable version (by git-bisect or similar)?
The reason is very simple: we had 4.6.1 archived and we already knew that it worked.
We had been using 4.6.1 for several months. We delayed upgrading to newer releases of Gambit simply to avoid destabilizing our toolchain. With the release of 4.6.6 I decided it was time to attempt the upgrade. We don't want to fall too far behind the current release.
However, we encountered a problem similar to the one you did, and so we chose to roll back to the toolchain we had previously been using, since we knew that it worked.
It still works. We'll try an upgrade again in the near future, and if we fail again, we'll roll back again.
We using 4.6.6, for now everything is perfect.
Here is what we do.
1. compile GambitREPL of gambit 4.6.6 with Xcode 4.0.2 on Snow Leopard. 2. compile and install gambit 4.6.6 with gcc-4.7 on working computer, Lion 10.7.4 2. copy libgambc.a from SL system to our project. 3. build project with latest Xcode (4.3.2)
On Jun 7, 2012, at 8:48 AM, mikel evins wrote:
On Jun 6, 2012, at 7:41 PM, Kirill Zorin wrote:
Is there any particular reason for using 4.6.1 (versus some other minor revision)? Was 4.6.1 found to be the latest iOS-stable version (by git-bisect or similar)?
The reason is very simple: we had 4.6.1 archived and we already knew that it worked.
We had been using 4.6.1 for several months. We delayed upgrading to newer releases of Gambit simply to avoid destabilizing our toolchain. With the release of 4.6.6 I decided it was time to attempt the upgrade. We don't want to fall too far behind the current release.
However, we encountered a problem similar to the one you did, and so we chose to roll back to the toolchain we had previously been using, since we knew that it worked.
It still works. We'll try an upgrade again in the near future, and if we fail again, we'll roll back again.
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Would you mind posting a link to your ARM libgambc.a file (and gambit.h)? Installing the gcc 4.7 toolchain on the Mac, especially as a cross-compiler, is a major pain, and I have a feeling other people will find this useful.
For whatever reason, not a single build I've got so far using build-gambit-iOS has been correct. Are there any extra special settings that need to be given to Xcode to make it cooperate with gambit?
Thanks.
On 2012-06-06, at 9:08 PM, Shihpin Tseng wrote:
We using 4.6.6, for now everything is perfect.
Here is what we do.
- compile GambitREPL of gambit 4.6.6 with Xcode 4.0.2 on Snow Leopard.
- compile and install gambit 4.6.6 with gcc-4.7 on working computer, Lion 10.7.4
- copy libgambc.a from SL system to our project.
- build project with latest Xcode (4.3.2)
On Jun 7, 2012, at 8:48 AM, mikel evins wrote:
On Jun 6, 2012, at 7:41 PM, Kirill Zorin wrote:
Is there any particular reason for using 4.6.1 (versus some other minor revision)? Was 4.6.1 found to be the latest iOS-stable version (by git-bisect or similar)?
The reason is very simple: we had 4.6.1 archived and we already knew that it worked.
We had been using 4.6.1 for several months. We delayed upgrading to newer releases of Gambit simply to avoid destabilizing our toolchain. With the release of 4.6.6 I decided it was time to attempt the upgrade. We don't want to fall too far behind the current release.
However, we encountered a problem similar to the one you did, and so we chose to roll back to the toolchain we had previously been using, since we knew that it worked.
It still works. We'll try an upgrade again in the near future, and if we fail again, we'll roll back again.
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
on Lion 10.7.4
first I install gcc-4.7 with brew then
% curl http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/source/gambc-v4_6_6... > gambc-v4_6_6.tgz % tar zxf gambc-v4_6_6.tgz % cd gambc-v4_6_6 % CC=g++-4.7 ./configure ---enable-single-host % make -j 3 % make install
;; -------------- on SL 10.6.8/ Xcode 4.0.2 % curl http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/source/gambc-v4_6_6... > gambc-v4_6_6.tgz % tar zxf gambc-v4_6_6.tgz % cd gambc-v4_6_6 # I have changed the build-gambit-IOS shell-script, replace gcc with g++. to get a libgambc.a which can be linked with C++ project # notice : if using g++ , GambitREPL.xcodeproj can not build correctly. but libgambic.a is ok. % cd contrib/GambitREPL % make ios ### this will recompile the Gambit runtime for the iPhone (real device and simulator)
You'll find the libgambc.a in GambitREPL/gambit-iOS/current/lib.
Here is my libgambic.a (compiled with g++)and gambit.h. http://goo.gl/HfxLT
On Jun 8, 2012, at 12:00 AM, Kirill Zorin wrote:
Would you mind posting a link to your ARM libgambc.a file (and gambit.h)? Installing the gcc 4.7 toolchain on the Mac, especially as a cross-compiler, is a major pain, and I have a feeling other people will find this useful.
For whatever reason, not a single build I've got so far using build-gambit-iOS has been correct. Are there any extra special settings that need to be given to Xcode to make it cooperate with gambit?
Thanks.
On 2012-06-06, at 9:08 PM, Shihpin Tseng wrote:
We using 4.6.6, for now everything is perfect.
Here is what we do.
- compile GambitREPL of gambit 4.6.6 with Xcode 4.0.2 on Snow Leopard.
- compile and install gambit 4.6.6 with gcc-4.7 on working computer, Lion 10.7.4
- copy libgambc.a from SL system to our project.
- build project with latest Xcode (4.3.2)
On Jun 7, 2012, at 8:48 AM, mikel evins wrote:
On Jun 6, 2012, at 7:41 PM, Kirill Zorin wrote:
Is there any particular reason for using 4.6.1 (versus some other minor revision)? Was 4.6.1 found to be the latest iOS-stable version (by git-bisect or similar)?
The reason is very simple: we had 4.6.1 archived and we already knew that it worked.
We had been using 4.6.1 for several months. We delayed upgrading to newer releases of Gambit simply to avoid destabilizing our toolchain. With the release of 4.6.6 I decided it was time to attempt the upgrade. We don't want to fall too far behind the current release.
However, we encountered a problem similar to the one you did, and so we chose to roll back to the toolchain we had previously been using, since we knew that it worked.
It still works. We'll try an upgrade again in the near future, and if we fail again, we'll roll back again.
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
On 2012-06-06, at 6:57 PM, Kirill Zorin wrote:
Hi all,
I've built (a slow version of) Gambit with llvm-gcc 4.2 on Mac OS X, targeted for the iPhone, using the build-gambit-iOS script, for the iOS 5.1 SDK. (I can't build it with latest clang, because for whatever reason Gambit's configure exits with various autoconf-related errors when clang is used.)
Can you please report to the ML what those errors are?
Marc
On Jun 8, 2012, at 10:41 AM, Marc Feeley wrote:
On 2012-06-06, at 6:57 PM, Kirill Zorin wrote:
Hi all,
I've built (a slow version of) Gambit with llvm-gcc 4.2 on Mac OS X, targeted for the iPhone, using the build-gambit-iOS script, for the iOS 5.1 SDK. (I can't build it with latest clang, because for whatever reason Gambit's configure exits with various autoconf-related errors when clang is used.)
Can you please report to the ML what those errors are?
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.
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?
Thanks.
On Jun 8, 2012, at 11:21 AM, Kirill Zorin wrote:
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?
Hrm. It's not in any way conclusive, and I may be reinfocing a mistaken hypothesis, but I do recall seeing several debugger-related warnings in the console log when I was reading through them.
I did more testing, and looks like things are fine when using GDB instead of LLDB(= the default in latest Xcode). Maybe this should be added to a wiki page somewhere?
On 2012-06-08, at 3:48 PM, mikel evins wrote:
On Jun 8, 2012, at 11:21 AM, Kirill Zorin wrote:
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?
Hrm. It's not in any way conclusive, and I may be reinfocing a mistaken hypothesis, but I do recall seeing several debugger-related warnings in the console log when I was reading through them.
at least some versions of LLDB are like the buggiest ever.
(consider example of lldb erratic behavior, provided by someone else, here both vars are int32_t:
(lldb) print _newestSentSequenceNumber< _newestSeenAckSequenceNumber (_Bool) $19 = true (lldb) print _newestSentSequenceNumber- _newestSeenAckSequenceNumber (int) $20 = 0 (lldb) print _newestSentSequenceNumber (EmiPacketSequenceNumber) $21 = 4456448 (lldb) print _newestSeenAckSequenceNumber (EmiPacketSequenceNumber) $22 = 4456448 (lldb)
)
2012/6/11 Kirill Zorin k.zorin@me.com
I did more testing, and looks like things are fine when using GDB instead of LLDB(= the default in latest Xcode). Maybe this should be added to a wiki page somewhere?
On 2012-06-08, at 3:48 PM, mikel evins wrote:
On Jun 8, 2012, at 11:21 AM, Kirill Zorin wrote:
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?
Hrm. It's not in any way conclusive, and I may be reinfocing a mistaken hypothesis, but I do recall seeing several debugger-related warnings in the console log when I was reading through them.
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
-
Kirill Zorin -
Marc Feeley -
Mikael -
mikel evins -
Shihpin Tseng