Matthew Dumbleton wrote: > > I have tried the new version you mentioned (via the ZIP archive) but this > doesn't seem to have resolved my issue. >
I'm working on some more changes that might help if the issue is actually related to threads being aborted. > > I did remove the abort call previously (after your valid comments) to test > and this made no difference so I'm not sure this is the root of the problem. > Very odd. Are you able to get a more detailed (native & managed) stack trace? Is this still with the debug build? I'm also very curious why the assert() failures indicating a corrupt heap we saw in the previous debug output are no longer showing up. Heap corruption is probably the root cause of the issue you are seeing. The question is, what is causing it? Even if the Thread.Abort issue was impacting you, it would most likely not manifest itself in a corrupted heap, it would probably just leak native resources. Is the latest interop debug output (with my enhanced diagnostics) any more revealing? I would like to see it if you have it saved somewhere because it shows the connection associated with the statements being finalized. > > I am simply starting the background thread and then flicking between forms when > the crash occurs. > Does the processor on the device being tested support more than one thread executing simultaneously? -- Joe Mistachkin _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
