Have you tried removing SQLCipher, and just use standard SQLite, to help
isolate the source of the problem?
hmmm... not good. i removed SQLCipher, and am linking with the
standard libsqlite, and the problem persists.
that points more towards it being something in our
hi all,
we are using sqlite on the iPhone, in conjunction with SQLCipher, so
the sqlite version is compiled in with SQLCipher. the version of sqlite is
3.7.2, and 4.3 of iOS.
i have an issue that suddenly started appearing all of a sudden. what
is happening is that the data
phil,
i think the easiest way is more or less like you said. issue the
BEGIN, and if you get an ok back, you aren't in a transaction, so you just
commit and close the db. otherwise you can wait and check later.
there may be a better way do it, but that is all i know of.
michael,
Have you run your test with and without crypto? If Apple can compile
3.6.23.2 to work you should be able to also (might be overly optimistic here
but compilers are 100% deterministic, although not necessartiliy 100% binary
match).
we have encrypted and read a database
hi all,
i've just discovered that the bug is there when compiling with the LLVM
compiler 1.6, which comes as a standard compiler with the iOS SDK, and is the
direction that Apple is moving towards.
the problem is NOT there when compiling with GCC 4.2.
the problem is
pavel,
I suspect that as soon as the application launches means that no
parallel threads are working yet (if they work already then look into
what those threads are doing). Then the problem could be in some
linking issues. E.g. you have some function that is named the same as
some library
michael,
just getting into it, but...
Did you increase the main thread size too?
i'm sure it's there, but i don't see a way to mess with the stack size
on the main thread. docs say that (for a secondary thread, doesn't mention the
main thread), that in order to be
dan,
I've have never tried this. But if I had the problem above, I would.
http://landonf.bikemonkey.org/code/iphone/iPhone_Simulator_Valgrind.20081224.html
looks interesting, but it doesn't support arm, which is where the
problem is showing up. the problem doesn't occur in the
simon,
The theory is that you are actually doing something wrong in your code, and
this triggers obvious problems on the iPhone itself because the iPhone itself
is so tight on space. However the simulator doesn't uncover these problems
because it has plenty of memory and stack space:
michael,
Well that's one you never mentioned...it works on the version with the SDK?
it's on the second to last line of my original message, an easy place
to miss. i should have put it in a more prominent place, as it is key.
What version of sqlite comes with that? And why are you
Note that this problem does /not/ happen if he accesses SQLite by calling the
version included in the iPhone frameworks. I still don't have a clue what
his problem is, but whatever it is it's not simple.
correct. and i agree, it probably isn't simple:-(
mickm
michael,
No such thing as close enough when it comes to different versions.
i do agree, although having tried 3 different version with exactly the
same behavior, i don't expect 3.6.23.2 to act any different, although you never
know.
Can somebody find the 3.6.23.2 amalgamation for
michael,
And now my 2nd reaction is potential stack overflow...
From what I can find IOS has a 1MB stack size for the main thread and 512K
for secondary threads. Mac OS X has an 8MB.
Are you settting the stack size?
the more i think about this, the more i agree. mainly
: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on
behalf of Mickey Mestel [mmes...@epocrates.com]
Sent: Friday, February 25, 2011 8:37 PM
To: sqlite-users@sqlite.org
Subject: EXT :[sqlite] long insert statement failing on iPhone
hi all,
new to the list
hi all,
new to the list.
we are compiling the sqlite.c amalgamation file into our project, as we
want to encrypt the database, and the sqlite that comes with the iOS sdk does
not allow for that.
we are developing on iOS 4.2, and to date have tried 3 different
versions
15 matches
Mail list logo
