I have some code in my application that looks something like this:
char *hash = (char*) sqlite3_column_text(get_bookmark, 0);
NSString* postHash = [NSString stringWithUTF8String:hash];
This works for me every time; I've never seen it not work. Most of my users do not experience problems (as far as I know). However I find that postHash is an empty string (#"") for some users some of the time.
Can anyone explain why?
Some more context/speculation:
This only seems to happen on jailbroken handsets. Is there anything different about them? I gather that there's usually less memory available. Anything else that could contribute here?
postHash is used in a table cell and is occasionally seen to be populated correctly so I'm reasonably confident that the database call should work. In fact, if the database also has an empty string it's because of a very similar piece of code so the question remains.
hash is certainly returning with a non-NULL value. If I force a NULL here, the app crashes. Similarly, postHash is not nil as that would also crash the app (for the same reason).
I am thinking that this is possibly memory related. If the method tries to allocate too much memory before -didReceiveMemoryWarning can get called what happens? I know that, at some point, the Springboard ejects the app. But is it possible that Cocoa returns a null string here rather than the expected value? I've heard of a few reports that, as far as I can tell, can only have been caused by an empty string being present where something longer should have been present.
Any other speculation, theories or ideas welcome.
However I find that postHash is an empty string (#"") for some users some of the time.
Can anyone explain why?
Because hash is an empty string (hash[0] == '\0').
I finally found the solution to this. I'm going to give Peter the accepted answer as he is right but the reason that I was getting an empty string is... interesting.
The database is populated correctly. The query is also correct. The difference between my phone and my users is that they have jail broken handsets. And apparently jail broken iPhones sometimes use a different version of SQLite than found in shipping versions of iPhone OS.
The change in version exposed a bug in my code that caused one of the parameters to be set incorrectly and sqlite3_column_text to return an empty string.
Related
I have 2 pieces of code :
It works normal
with ADOTemp do
begin
SQL.Clear;
SQL.Add('INSERT INTO documents');
SQL.Add('(document_date,fk_id_status,money_direction,');
SQL.Add('paid,addition,saving,fk_id_base,fk_id_user)');
SQL.Add('VALUES ');
SQL.Add('(CONVERT(DATE,GETDATE(),103),:pfk_id_status,:pmoney_direction,');
SQL.Add('0,0,0,'+IntToStr(p_id_base)+',:pfk_id_user)');
Parameters.ParamByName('pfk_id_status').Value := p_id_status;
Parameters.ParamByName('pmoney_direction').Value := p_money_direction;
// Parameters.ParamByName('p').Value := p_id_base;
Parameters.ParamByName('pfk_id_user').Value := fMain.ApplicationVariablers.user_id;
ExecSQL;
end;
It does not work and returns a terrible error
with ADOTemp do
begin
SQL.Clear;
SQL.Add('INSERT INTO documents');
SQL.Add('(document_date,fk_id_status,money_direction,');
SQL.Add('paid,addition,saving,fk_id_base,fk_id_user)');
SQL.Add('VALUES ');
SQL.Add('(CONVERT(DATE,GETDATE(),103),:pfk_id_status,:pmoney_direction,');
SQL.Add('0,0,0,:p,:pfk_id_user)');
Parameters.ParamByName('pfk_id_status').Value := p_id_status;
Parameters.ParamByName('pmoney_direction').Value := p_money_direction;
Parameters.ParamByName('p').Value := p_id_base;
Parameters.ParamByName('pfk_id_user').Value := fMain.ApplicationVariablers.user_id;
ExecSQL;
end;
Error on image, line 1917
It seems that this question is in reference to your earlier question: Delphi, error :"Access violation at address xxxxxxxx. Read of address yyyyyyyy", at AdoQuery.SQL.Text:='''
You had added and accepted an answer there along the lines seen in this question. The error message, an AV in msvcrt.dll is indicative of a serious programming error. Perhaps a heap corruption. Perhaps something else. The change you made that stops the error occurring does not really fix the problem. The problem will still be there, lying dormant. You just got (un)lucky that the change you made appeared to fix the problem.
Access violations are not always reproducible. That's just their nature. When you encounter one you need to understand why it happens. Simply using trial and error to re-organise code from a completely different location will never lead to the real solution.
What you should be doing is tracking down the real cause of the problem. Do that, fix it, and either version of the code above will work. This is probably not the answer you are wanting to get. You may very well not want to accept what I say. But, speaking from experience, until you recognise that you have a more serious problem, you will make no headway here.
Looking at your code in the bitmap...I'm pretty sure you access violation is because of what David just said...you have serious Memory problems in your code...Your not freeing your objects...that you are creating...Anytime you pass a nil reference to Owner in a TComponent Constructor...your telling the compiler...that you know what your doing and will free it when your finished with it...Matter of fact good practice is to always free objects that you declare and use exclusively in the scope of your method.
procedure TForm1.MyMethod;
var
a_MyComp: TMyComp;
begin
a_MyComp := TMyComp.Create(nil);
Try
//use my a_MyComp...
Finally
a_MyComp.Free;
End;
end;
Check out your code in CreateNewDocument...you'll notice that your not freeing your AdoTemp.
-Rick
Access violation exceptions (AVs) tell you that you have made a mistake in the memory access of your program. However, the way access violations work: they are unable to guarantee always detecting the error every time you make a mistake. (Sometimes you get un-lucky and no access violations are raised, but the mistake is still there causing other things to quietly go wrong inside your application.)
You can think of the memory available to your program being represented as below (where "." means the memory is not allocated to anything, and "A" means the memory is allocated to something within your program: e.g. object, local variable, parameter, machine code).
[.......AAA..AAAA.....AA......A...A...........AAA....A.......AA.........AAAAA]
Suppose you create some object; this will require memory to be allocated for the object itself. If the object in turn creates child objects, this will also be allocated in memory. (I'll use "O" and "C")
/-ref--\
[.......AAA..AAAAO....AAC.....A...A.....C.....AAA....A.......AA.........AAAAA]
\-ref------------------/
Note that within the memory allocated to O, it might hold references to its child objects.
Conversely to the above, whenever an object is destroyed, its memory is deallocated. Let us suppose you have made a mistake in your memory access, and something has destroyed one of O's child objects before O has finished using it.
/-ref--\
[.......AAA..AAAAO....AAC.....A...A...........AAA....A.......AA.........AAAAA]
\-ref------------------/
If O now tries to use its second child object, you will get an access violation. However, you might be un-lucky and not get an access violation showing your earlier mistake IF:
You destroy O without it trying to do anything to the second child object.
Or you first create a new object that happens to be allocated in the exact same place the child object was.
The second situation tends to be worse than the first, because every time C2 is used on the assumption that it is the correct child of O: unexpected results are produced and an incorrect values are written in memory. These incorrect values may be important data, or references to other objects (making the problem get worse over time).
So: Whenever yo do get an access violation, thank your lucky stars and hunt down the root cause of the problem.
NB! NB! I cannot stress the importance of the above enough.
Investigating your particular problem
First note, when an exception pauses in the debugger, the code usually points to the next line that would have been executed if not for the exception. (This doesn't affect anything here, because the previous line is also ADOTemp.SQL.Add; - the point is be prepared to consider the previous line as the cause of an exception - and test to confirm it!)
Useful tip: When an exception is thrown within Delphi/Third Party code, it can be useful to build with Debug DCU's or recompile Third Party source with debug information to get closer to the actual line raising the exception. (This can even be useful in situations like this where the error appears to be inside a Microsoft DLL.)
Looking at your screen-shot, the exception is thrown from a brand new instance of TADOQuery. Now there really isn't any sensible explanation for a brand new query to be throwing access violations when simply adding text to its SQL query. This strongly implies a corruption problem as described earlier.
One possibility would be another thread interfering with this one. (NOTE: even if your application isn't multi-threaded, the ADO objects do have built-in support for asynchronous operations.) However, I'm going to ignore that possibility for now because threading issues tend to be less consistent than you've implied this one is.
So, assuming you have a memory access problem somewhere else that is only manifesting here with a brand new TADOQuery (used correctly at least up to the point of the AV) - what other objects are interacting with this query to possibly cause corruption?
ADOTemp.Connection := fMain.ADOConnection;
There is a very strong possibility that commenting out the above line would also eliminate your access violation. So what are the possible problems:
fMain might have been destroyed prematurely and is now a dangling pointer meaning the code to return ADOConnection could do any of a number of unexpected things.
Any of the code backing fMain.ADOConnection may be referencing corrupted memory or dangling pointers; this includes the returned connection itself.
NOTE: One very common cause of invalid memory access is to have a function such as GetADOConnection that does not correctly initialise its Result. So in some cases it returns a 'random' address in memory, resulting in all sorts of unexpected behaviour when something tries to use the connection.
Is your ADOConnection created on a different thread, and being used by multiple threads?
PS: Don't forget to follow Rick's advice, and make sure you destroy the query when you've finished using it. Who knows, there might be an internal bug in ADO that when it runs out of a particular internal resource (due to queries not being destroyed), that causes ADO to start throwing AVs.
NOTE: You should be able to test my theory without altering functionality by simply changing the ADOTemp.Connection := ... line. Simply assign a connection string to the query instead of a connection object. However, if that solves (or more correctly stated: hides) the problem, please follow my advice, and hunt down the root cause of the AV.
I have an app submitted to Apple Store, and it passed. But I found there was a bug will make the app crash. Finally, I found the real problem is a snap of code has the opposite result.
code:
CGPoint now;
CGPoint old;
UIView *lastDot;
now = dotView.center;
if(lastDot){
//release version, will go here. then crashed.
old = lastDot.center;
}else{
//debug version, will go here. run ok.
}
I declare a UIView pointer, and check it with "if statement",
UIView *lastDot;
the debug version consider the lastDot as nil, but the release version think is not null.
can anyone give me any idea? thank you.
Depending on your compiler settings, debug builds usually initialize pointers to some sentinel values like 0xcccccccc.
UIView *lastDot = nil;
Should work as expected.
The issue is due to uninitialized pointer.
Initialize it to nil for avoiding such troubles.
UIView *lastDot = nil;
I know you already got the answer.
I just want to add some points too:
Pointers are just like any other variable: if you don't explicitly set
them to a value, the value will be undefined means a random value. If
you then accidentally access the variable, very bad things can happen.
Sometimes people recommend that pointers be assigned to NULL, the
universal value meaning "this pointer doesn't point at anything",
because a lot of code already checks for NULL pointers. For example,
if you call [nil release], it's guaranteed to do nothing. If you
passed an uninitialized pointer in who knows what would happen.
It's really just a safeguard against programmer error. If you
initialize pointers to a reasonable value, it's less likely that an
uninitialized pointer will cause a system crash sometime in the
future.
When you don't initialize a pointer and then try to use it, you have 3
problems:
It might be pointing at memory you don't have access to, in which case it causes a segmentation fault and crashes your program
It might be pointing at real data, and if you don't know what it's pointing to, you're causing unpredictable (and very hard to debug)
changes to your data.
You have no way of knowing if it's been initialized or not - because how do you tell the difference between a valid address and the address
that happened to be there when you declared the pointer?
Initializing every pointer to nil seriously decreases or eliminates
those problems:
If I try and use it, it will still segfault, but at least I can test if it's NULL and act accordingly - I can know that it WILL segfault,
and do something else. If it's a random value, I don't know anything
until it crashes.
If you initialize it to nil, I can't make it point to data unless I explicitly tell it to. So I only modify what I meant to.
As implied above, I can tell when I've initialized it and when I haven't, and make a decision.
Obviously it's a matter of style, and it is possible to write an
application where variables are only initialized to their intended
value, but I feel it is safer and easier to initialize them to nil
always. Even the best programmers make typos - nil makes it easier
to know when that's happened.
Reference :
eskimo
Initializing pointers always necessary
I have a pretty weird problem in my iPhone app which is, I think, related to memory getting corrupted:
At one point, I need to sort an array, which I do with -[sortArrayUsingFunction].
The result is not correct unless I either allocate some memory with something like void *test = malloc(2 * sizeof( int )) before the method call or have, e.g., a call to NSLog() (which is never invoked) in the sorting function.
In other words: the sorting only works if I slightly increase the memory that was used before calling the sorting function. I think this is because at some point, memory gets corrupted.
How do you debug something like this?
It sounds like some of your code is using already released objects. A lot of help with debugging this kind of errors is provided in Apple’s great Mac OS X Debugging Magic tech note, especially the foundation part.
For your case I'd disable autorelease pools (setting the environment variable NSEnableAutoreleasePool=NO) or use the zombie feature (NSZombieEnabled=YES) to find places where you send messages to released objects.
Try running your program in the simulator under Valgrind:
http://valgrind.org/
And how to use it under the simulator:
http://landonf.bikemonkey.org/code/iphone/iPhone_Simulator_Valgrind.20081224.html
You may have to change the VALGRIND path in the code example depending on where it gets installed.
Such things can be a challenge to debug. There are some tools for detecting out-of-bounds accesses and such on other platforms, so I presume there would be something for the iPhone, however I don't know of any.
Perhaps you should store two copies of the array, and compare them for differences. Print out the differences. The nature of the "junk" that was introduced to one of the arrays might give a hint as to where it came from.
Also just go through the code that runs before this point, and re-read it (or better yet, get someone else to read it). You might spot a bug.
Ok so this is gonna be a bit of a shot in the dark without you being able to see my application!
I have a bug. I have a SwimmingPool class, my app passes the pool from a tableview into a detail view where you can see all the swimmingPool class fields. You can then click on the individual detail, edit it, and then save it. The 'original' pool facility is copied and passed to the view controller responsible for actually making changes. If the user presses save, the fields are copied from the copy into 'original'
switch (self.sectionFromParentTable) {
case KNameIndex:
self.thePoolFacility.name = self.thePoolFacilityCopy.name;
self.thePoolFacility.type = self.thePoolFacilityCopy.type;
break;
case KAddressIndex:
self.thePoolFacility.address = self.thePoolFacilityCopy.address;
break;
case KPhoneNumberIndex:
self.thePoolFacility.phoneNumber = self.thePoolFacilityCopy.phoneNumber;
break;
case KWebAddressIndex:
self.thePoolFacility.webAddress = self.thePoolFacilityCopy.webAddress;
break;
case KPricesIndex:
self.thePoolFacility.prices = self.thePoolFacilityCopy.prices;
break;
case KPoolIndex:
self.thePoolFacility.pools = self.thePoolFacilityCopy.pools;
default:
break;
}
[self.navigationController popViewControllerAnimated:YES];
Can I have some guesses at a bug that does the following:
The bug results in the changes done
to a class' fields not being saved. In particular a class called TimeEntry, in a mutable array called Monday in a Dictionary called TermTimes in a class called pool and then in a mutable array called Pools.
It's appears random. Sometimes it
works perfectly. Sometimes it
doesn't! I can't recreate the error,
only if I'm lucky can i get it not
to save. My hunch is it could be
time sensitive. For example, If I am
entering a timetable for Pool
opening times, if i quickly add a
few entries and save it usually
works fine. If I fill in a whole
timetable then it more than not
doesn't save.
The app doesn't crash.
It's infuriating the try and debug an error that seems to happen at random. Any hints on such an epic bug hunt?
One of the best ways to tackle this type of problem (where it seemingly can't be reproduced reliably) is to insert logging code in various areas where you expect certain things to be happening. Log places that errors could occur, log what values you are expecting and what you have, etc. Next, try, try, try until you can reproduce the bug.
Unlike before, you now have a log to look at and see where things went wrong. If things still look correct everywhere, insert some more logging code elsewhere. If you see something go wrong, but don't understand it, put more logging code in that area and keep narrowing the problem down.
Hopefully this will lead to new hypotheses about how the bug happens, and you will be able to reproduce it under the debugger reliably and fix it!
As duffymo mentioned, multithreading could be the culprit, and would be a good place to investigate first if you're knowingly using multiple threads.
"random" and "hard to reproduce" makes me think that this is an issue having to do with multi-threading. Race conditions are very hard to reproduce and debug. You'll need to make sure that you have exclusive rights to the resources you need to perform this operation.
My suggestion is to look for nils. Any method call on a nil object simply does nothing and returns nil, so any time you're expecting a method to be called and it isn't, you should look for that. (.foo = is the same as setFoo:, so nil.foo = 1; will do nothing.)
Thanks for all your answers. It's now fixed.
For those interested I'd forgotten to add a cellidentifer in the XIB of my cell subclass.
cellForRow: method was therefore creating a new cell every time. The memory got filled up very quick. It then seemed as though my app was automatically trying to cut the fat by forcing another tableView out of editing mode and not managing my instances properly.
Again it's a memory problem. Isn't this always the case!?!
The clue was a one off 101 error in the console indicating my app was using too much memory. Oh and a slow scrolling tableView.
I have this line of code (splits is an instance variable):
splits = [[NSMutableArray alloc] initWithObjects:[NSMutableArray array]];
This code is obviously wrong (it should be nil-terminated), however it runs fine in the simulator, even though it throws an EXC_BAD_ACCESS on the device. My question is why does the simulator not throw an error?
Kyle
The actual outcome depends on the memory contents. It is quite possible that the memory layout on the simulator contains a zero right after the address of the first parameter (the anonymous array). This zero gets interpreted as if you would close the argument list with nil and everything works fine. (P.S. There is an interesting macro called NS_REQUIRES_NIL_TERMINATION for such cases, although it obviously would not help here.)
The iPhone has much less memory than your computer. The area in memory for the stack could have been set to 0x00 (nil) before being used by the initWithObjects function. When the parameters are sent to the initWithObjects function and the stack is alloated, that memory space on the computer is more likely to be preset to 0x00 than the iPhone because the same memory space is used less often. So it is likely that the nil is being read from a spot in memory set to 0 already.
If you fill up your memory on your computer, and then run the simulator, the simulator may be more likely to crash like the iPhone.
Buffer overflows result in undefined behavior. They are not guaranteed to cause an access violation (or even a noticeable bug). On modern machines, they will cause an access violation if you happen to step on "someone else's" memory, but probably not if you're just reading junk from your own stack.
Basically, you just need to be careful, and can try tools like Mudflap and Valgrind to help you out (these particular two are more meant for C/C++, and I don't know how well they apply to Obj-C).