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: busting the stack never
> makes it run into the space used for normal memory because they're so far
> apart.
>
> The idea of valgrind is to be completely paranoid about the execution
> environment, spotting cases where things change when the instruction that was
> just executed shouldn't change them, making sure the heap changes only one
> item at a time, etc.. Running this on the simulator may make it as sensitive
> to bad code as the iPhone itself.
>
> I'm not saying it'll definitely spot your problem, but it may help.
yup, all good points. this is a tough one, because it is happening so
deep in the sqlite code. we aren't seeing, (to our knowledge, yet), similar
issues or problems anywhere else in the code. in a way it's hard to imagine
that it is the sqlite code, as it is happening across 3 version exactly the
same, but on the other hand it isn't happening in the sqlite that comes with
the iOS SDK.
we are trying to decide where to go with this, so may follow up on
Valgrind.
thanks,
mickm
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
