Double changing value on release version? - iphone

My app works perfectly on the debug version, but when I create a release version and install it on my iphone, double values mysteriously change value. I know this by looking at the logs.
double amountComplete;
double possibleTotal;
for (int i = 0; i<self.tasksArray.count; i++) {
Task *myTask = [self.tasksArray objectAtIndex:i];
possibleTotal = possibleTotal + [myTask.size doubleValue];
if (myTask.completed==[NSNumber numberWithInt:1]) {
amountComplete = amountComplete + [myTask.size doubleValue];
}
}
Amount possible ends up being a hige number such as 12312213.0000.
How do I fix this and why does it only happen on the release version?

You ignored the "variable amountComplete is used uninitialized" warnings. Change the declarations to
double amountComplete = 0;
double possibleTotal = 0;
(In debug mode, entirely by accident, these variables' storage locations happen to contain floating-point zeroes on entry to the loop. Remember, undefined behavior includes the possibility of everything appearing to work just fine.)

Related

Unity mapping keys incorrectly

Just to illustrate with some code, Unity is not recognizing the correct alpha key codes the way it is supposed to. Sometimes it recognizes the keys appropriately, but not every time. This happens even when I run a few simple lines of code.
for(int index = 0; index < nextStates.Length; index++)
{
if (Input.GetKeyDown(KeyCode.Alpha2 + index))
{
state = nextStates[index];
}
}
The above code, for example, recognizes the 2nd key on my keyboard. But not every single time and it's pretty basic. What am I doing wrong?

Assertion Failure in Calculator Program

So I'm working on a simple calculator program to get used to cocoa and objective C. I've redone the whole thing multiple times and every time I finish coding, the first time i build it, it works fine, but every time after that the window wont launch and it gives me these errors:
2013-01-11 10:32:14.760 Visual Caluclator Fix[39892:403] *** Assertion failure in -[NSTextFieldCell _objectValue:forString:errorDescription:], /SourceCache/AppKit/AppKit-1138.47/AppKit.subproj/NSCell.m:1564
2013-01-11 10:32:14.762 Visual Caluclator Fix[39892:403] Ignoring exception raised in __-[NSPersistentUIManager restoreAllPersistentStateWithTalagentWindows:registeringAsReadyWhenDone:completionHandler:]_block_invoke_3: Invalid parameter not satisfying: aString != nil
I've concluded that the problem lies in my textEdited method, because when I comment the code inside of it out, the program has no issues running; however, I have no idea why this is, or why it would run the first time and not any subsequent times. When I put in an exception breakpoint, it points me to the one line in the updateUI method and the call to [self updateUI] in the textEdited method. The following code is the textEdited method and the other methods it references.(I'm fairly sure there's nothing wrong with the solve method because I used it in a command prompt calculator and it worked great. Also, I know this is a pretty convoluted way to program a calculator, with the strings and everything, but I was just trying to integrate the code I already had for the command prompt program into a cocoa program.)
In the AppDelegate class:
- (void)updateUI{
[self.calculationView setStringValue: self.calculation.calcString];//Exception breakpoint points here
}
- (IBAction)textEdited:(id)sender {
self.calculation.calcString = self.calculationView.stringValue;
[self.calculation solve];
[self updateUI];//Exception breakpoint points here
}
In the Calculation class:
- (NSString*)solve{
for (int i = 0; i < [self.calcString length]; i++) {
NSRange nextChar = NSMakeRange(i, 1);
if ([[self.calcString substringWithRange: nextChar] isEqualToString: #"*"]||
[[self.calcString substringWithRange: nextChar] isEqualToString: #"/"])
[self calcTerm: i];
}
for (int i = 0; i < [self.calcString length]; i++) {
NSRange nextChar = NSMakeRange(i, 1);
if ([[self.calcString substringWithRange: nextChar] isEqualToString: #"+"]||
[[self.calcString substringWithRange: nextChar] isEqualToString: #"-"])
[self calcTerm: i];
}
return self.calcString;
}
This might help with your problem:
http://www.raywenderlich.com/10505/my-app-crashed-now-what-part-2
The site explains how assertion errors work and demonstrate how you would fix an error like that.
It sounds to me like something in calcTerm: is setting calcString to nil. Thus, when you retrieve it later to set the field's string value to it, you end up setting the field's string value to nil, which it doesn't like.
You can check this by logging the value of calcString just before the end of solve. Then, start stringing up log statements and/or breakpoints in calcTerm: to find out how you're swapping out your string for nil.

Page fault with newlib functions

I've been porting newlib to my very small kernel, and I'm stumped: whenever I include a function that references a system call, my program will page fault on execution. If I call a function that does not reference a system call, like rand(), nothing will go wrong.
Note: By include, I mean as long as the function, e.g. printf() or fopen(), is somewhere inside the program, even if it isn't called through main().
I've had this problem for quite some time now, and have no idea what could be causing this:
I've rebuilt newlib numerous times
Modified my ELF loader to load the
code from the section headers instead of program headers
Attempted to build newlib/libgloss separately (which failed)
Linked the libraries (libc, libnosys) through the ld script using GROUP, gcc and ld
I'm not quite sure what other information I should include with this, but I'd be happy to include what I can.
Edit: To verify, the page faults occurring are not at the addresses of the failing functions; they are elsewhere in the program. For example, when I call fopen(), located at 0x08048170, I will page fault at 0xA00A316C.
Edit 2:
Relevant code for loading ELF:
int krun(u8int *name) {
int fd = kopen(name);
Elf32_Ehdr *ehdr = kmalloc(sizeof(Elf32_Ehdr*));
read(fd, ehdr, sizeof(Elf32_Ehdr));
if (ehdr->e_ident[0] != 0x7F || ehdr->e_ident[1] != 'E' || ehdr->e_ident[2] != 'L' || ehdr->e_ident[3] != 'F') {
kfree(ehdr);
return -1;
}
int pheaders = ehdr->e_phnum;
int phoff = ehdr->e_phoff;
int phsize = ehdr->e_phentsize;
int sheaders = ehdr->e_shnum;
int shoff = ehdr->e_shoff;
int shsize = ehdr->e_shentsize;
for (int i = 0; i < pheaders; i++) {
lseek(fd, phoff + phsize * i, SEEK_SET);
Elf32_Phdr *phdr = kmalloc(sizeof(Elf32_Phdr*));
read(fd, phdr, sizeof(Elf32_Phdr));
u32int page = PMMAllocPage();
int flags = 0;
if (phdr->p_flags & PF_R) flags |= PAGE_PRESENT;
if (phdr->p_flags & PF_W) flags |= PAGE_WRITE;
int pages = (phdr->p_memsz / 0x1000) + 1;
while (pages >= 0) {
u32int mapaddr = (phdr->p_vaddr + (pages * 0x1000)) & 0xFFFFF000;
map(mapaddr, page, flags | PAGE_USER);
pages--;
}
lseek(fd, phdr->p_offset, SEEK_SET);
read(fd, (void *)phdr->p_vaddr, phdr->p_filesz);
kfree(phdr);
}
// Removed: code block that zeroes .bss: it's already zeroed whenever I check it anyways
// Removed: code block that creates thread and adds it to scheduler
kfree(ehdr);
return 0;
}
Edit 3: I've noticed that if I call a system call, such as write(), and then call printf() two or more times, I will get an unknown opcode interrupt. Odd.
Whoops! Figured it out: when I map the virtual address, I should allocate a new page each time, like so:
map(mapaddr, PMMAllocPage(), flags | PAGE_USER);
Now it works fine.
For those curious as to why it didn't work: when I wasn't including printf(), the size of the program was under 0x1000 bytes, so mapping with only one page was okay. When I include printf() or fopen(), the size of the program was much bigger so that's what caused the issue.

notation problem

When i typed [lat1 = newLocation.coordinate.latitude]; its telling expected : before ] token like that. whats my fault? as i am new to this domain., please ayone guide me.
Thanks In Prior....
If you are trying to compare lat1 and newLocation.coordinate.latitude, the correct statement would be:
if (lat1 == newLocation.coordinate.latitude) {
// do something here
}
If you are trying to assign the value of newLocation.coordinate.latitude into lat1, the correct statement is:
lat1 = newLocation.coordinate.latitude;
If you are trying to do the first thing and the compared variables are floating point numbers, then you probably want to check if they are close enough instead of equality:
if (fabs(lat1 - newLocation.coordinate.latitude) < someLittleDistance) {
// close enough
}
…where of course you will have to define someLittleDistance.
Try the following..
Remove the [] brackets from your line it must be
lat1 = newLocation.coordinate.latitude;
When xCode behaves like this, it probably wants to say that something is the method or it thinks of something like a method. Dot-notation in Objective-C as usual is some kind of equivalent of the setter. For example
ObjectA.property1 = value;
is equivalent of
[ObjectA setProperty1:value];
And in the last case, xCode expects to see : after the setter call and a value after the column.

Assigned value is garbage or undefined logic error in XCode

I am updating our iPhone app to iOs4 and I ran into an issue "Pass-by-argument in function call is undefined" in the code
for (i = 0; i < self.numberOfSegments; i++) {
[self setWidth:round(width[i]) forSegmentAtIndex:i];
}
Which is fair enough, width[i] hasn't been initialized. Updating the code (below) however gives me this new error, "Assigned value is garbage or undefined". Reading up on this I think that segWidth retains its value as garbage - is that correct and if so how do I clear it?
for (i = 0; i < self.numberOfSegments; i++) {
float segWidth = (float)width[i];
[self setWidth:round(segWidth) forSegmentAtIndex:i];
}
------------- EDIT ------------------
Thanks for the replies guys. More information as follows;
A genericised version of the method is shown below as someFunction. I have removed the ugly cast but still see the "Assigned Value is Garbage or undefined" logic error for the line segWidth = width[i];
I agree it appears the value width[i] doesn't have clear initialisation, I am unsure if it's my lack of understanding of basic Obj-c float types or if there is a logic flaw in my assignment syntax?
- (void)someFunction
{
unsigned int n = self.numberOfSegments;
float width[n];
for (i = 0; i < n; i++) {
width[i] = someFloatValue;
}
...
for (i = 0; i < self.numberOfSegments; i++) {
float segWidth = 0.0;
segWidth = width[i];
[self setWidth:round(segWidth) forSegmentAtIndex:i];
}
}
Definition of setWidth is:
- (void)setWidth:(CGFloat)width forSegmentAtIndex:(NSUInteger)segment; // set to 0.0 width to autosize. default is 0.0
I'm assuming that you are calling:
- (void)setWidth:(CGFloat)width forSegmentAtIndex:(NSUInteger)segment
And that Pass-by-argument in function call is undefined is actually the LLVM static analyzer error when you do Build and Analyze. (Both rather important data points -- passing along exactly what you were doing and exactly what the output was is quite helpful).
And you say that width[i] hasn't been initialized.
Your fix of adding float segWidth = (float)width[i] very much should cause the analyzer to complain with ** Assigned value is garbage or undefined**. You haven't actually set width[i] to anything. I would suggest filing a bug against the static analyzer, though, because that first error message is really quite thoroughly obtuse.
As Joshua also said, that cast is really weird, too. In general, in Objective-C you should very rarely have to use type casting and pretty much never use it on scalar types.
Consider the two loop counts:
for (i = 0; i < n; i++) {
...
}
for (i = 0; i < self.numberOfSegments; i++) {
...
}
The static analyzer doesn't know that n == self.numberOfSegments and, thus, must assume that the second loop could loop longer than the first. Now, you might say, "But I assigned n = self.numberOfSegments above?!"
You did, but that value could have changed between the first call and second call and, thus, the analyzer has correctly identified that you might be using an uninitialized value.
(Really, it should be saying that you might run off the end of the array, because that is the real risk).