Ladies and Germs,
A colleague of mine reports that calloc() works correctly on his
iPhone 3GS, in that it always returns NULL when he allocates too much
memory. He is then able to back out of all the allocations and exit
his minimal test case App without it getting killed by the system.
I suspect now that the death of my App is not due to the conscious
design of Apple's iOS architects, but some other bug that occurs in my
particular configuration.
I asked him to tell me his configuration details, but have not yet
received his response.
I have only tested on an iPhone 4 with iOS 4.3.5. I also own a
first-generation iPad with 3.2.2 and a first-gen iPhone with 3.1.6.
I'll test those as well, and all three of my devices with iOS 5.0 and
the 5.0.1 beta, but not this evening as I was up all night last night
and so I am now totally thrashed.
My memory is quite hazy as it has been quite a long time, but I would
swear this worked properly on a third-generation iPod Touch. I
remember that now as back then I filed a bug that reported that the
maximum grid size in the Simulator was quite a lot more than on my
iPod.
My bug report suggested that Apple more-accurately simulate the memory
available on physical devices by calling the setrlimit() system call
just before entering main() in simulated Apps, but in all this time,
Apple's only response has been a request that I attach a minimal test
case to my report.
Look man, it's not Rocket Science to write a loop that allocates a
whole bunch of memory a whole bunch of times, then report to the user
how many of those allocations actually succeeded.
Rather than attach a minimal test case to my bug report, I got really
really really pissed off at whatever Apple tools engineer who couldn't
take time out from his Angry Birds sesssion to write a twenty-line
test tool that would verify a bug whose fix would be just one line of
code, which fix would prevent all of us iOS developers, as well as
Apple's own iOS App developers, from shipping totally buggy products
to end-users.
That's a hint, by the way, for any of Apple's iOS tools engineers who
might be reading this diatribe.
Is Radar back up yet? Hot Damn!
Mac OS X virtual memory allows iPhone Simulator Apps to have too much memory
rdar://8419428
That bug report indicates that calloc() did in fact return NULL on
allocation failure on my iPod. I didn't report the configuration
details, I'm afraid, but I'm pretty sure my iPod was a
third-generation unit.
Earlier today I stumbled across a 100% repeatible Thumb-2 code
generation bug in a completely different part of my program. The bad
machine code is precisely the same at all the available levels of
optimization: -O0, -O1, -O2, -O3 and -O4.
What is really bizarre is that the bad machine code is only generated
for Release builds that are built with Apple's LLVM 3.0 compiler for
physical iOS devices.
Debug builds do not exhibit the bug at any optimization level.
It's goes more or less like this:
float foo = 0.0;
useconds_t delay = foo * (float)500000;
if ( delay >= 4000 ){ // 1/250th of a second
usleep( delay );
}
My intention is to suspend my process if the user's setting of my
App's speed control is measurably less than the maximum possible
speed.
That's because there is quite a lot of overhead for any system call in
a preemptive multitasking OS that has hardware memory protection. I
figured my App would run just a little bit faster if I didn't sleep at
all unless the speed control was set to a delay that would be still
measurable even if there was no overhead at all to the usleep() call.
In Debug mode, this code works perfectly for all optimization levels.
In Release mode, the branch is taken and usleep() is called for all
optimization levels, even when delay is zero!
The Thumb-2 assembly code is completely different for the two kinds of
builds, but for a given build, the assembly is largely the same among
all the optimization settings. I expect that the Debug build has
quite different machine code to make source code debuggers work
better.
i386 Simulator builds do not have the bad machine code at all, for
either Debug or Release.
The chances are pretty good that the iOS App Death all you Apple
FanBois are claiming is The Way Life Should Be(TM) is, in reality, bad
machine code generation on the part of Apple's LLVM 3.0 toolchain!
I have seen stranger compiler bugs.
Back in 1990 or so I found a code generation bug in the Macintosh
Programmer's Workshop C compiler for the 680x0. While regressing it I
discovered that increasing the length of certain symbol names in my
source code led the compiler to crash while it was compiling my
source! I expect the bad machine code was the result of a buffer
overflow that corrupted the compiler's memory, but not bad enough as
to cause a crash.
A good three years passed before I received an Apple Developer CD with
a build of MPW that discussed my bug in its release notes. It went on
at some length about how to reproduce the bug and then just said:
"Don't Do That!"
It had something to do with a C function that returned a pointer to a
Pascal function. Pascal subroutine calling conventions different from
the C conventions. Pascal subroutines are not used in OS X or the
iOS, but they were everywhere in Classic.
Radar was down when I tried to file a bug report, so I posted it to
the LLVM-Dev mailing list instead, which I expect most of Apple's
tools engineers read:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-November/045294.html
I do not yet have a minimal test case or a thorough regression, but
when I do I'll post them here, and will post a follow-up as a new
thread in the Xcode-Users list:
http://www.dulcineatech.com/bug-reports/xcode/4.2/llvm/
Nighty-Night! Don't Let The Code Bugs Byte.
Don Quixote
--
Don Quixote de la Mancha
Dulcinea Technologies Corporation
Software of Elegance and Beauty
http://www.dulcineatech.com
quix...@dulcineatech.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
