> Since my code works for 3 records, it is probably 'correct'.
That is nowhere close to true. However, it does suggest a debugging strategy. After each record, do a heap integrity check.
I must also submit that your definition of "works" is far too narrow. Maybe your code produces the results you expect 3 times, but it clearly causes some degradation of **something**, such that successive calls have a lower probability of satisfying even your weak kind of "works".
> I've run out of options for debugging the reason for the error I am getting after 3 rows. Hopefully, someone can share their insight so I can solve this problem.
Well, I already suggested an approach. How did that work out? The result may very well show you that whether "it works" depends on something in your code.
You did not answer Keith's question, "Are you attempting to 'hang onto a pointer' after your callback returns?" This leads me to suspect you do not know what he means or why that programming sin should be among your chief suspects. (The values you cite in your not-quite-an-answer to him are **not** literals.)
> When I call sqlite3_exec from my code, on which line in sqlite3.c does it land?
If you can find "sqlite3_exec(" in sqlite3.c, you will find instances of that text in 4 categories: (1) Inside of comments; (2) A forward declaration; (3) In other code calling into sqlite3_exec(); and (4) A definition of sqlite3_exec(...). When you call it, that last is where your call "lands".
I feel compelled to note that somebody who cannot look at sqlite3.c to find a function definition is unlikely to be able, absent extremely compelling evidence, to correctly diagnose that a bug lies outside his own code and hence must be in somebody else's code. The sqlite3_exec() API is used successfully by many thousands of SQLite library users, and the whole library API is tested extensively for every release and intervening code drop. The overwhelming likelihood is that your callback is doing something that cannot work reliably. If it passes around soon-to-be-stale pointers to dynamically allocated memory, to be used after they are in fact stale, (such as Keith and I suspect leading to our suggestions), that is what you must stop doing.
Your debugging effort only going to be hindered by your wish to absolve your own code. That is an attitude you would do better to shed. Your goal during debugging is to figure out what is going wrong, with enough detail that it is reasonable to decide what code is violating its (explicit or implicit) contract. Only then can you proclaim the location of bug. You are nowhere close to that point, and having counted loops before a crash is not a sign of being close.