Object destructors can be tricky in a GC'd language. It looks like you're accessing a deallocated pointer in your destructor. Order of collection/destruction is not guaranteed.
Bane Wrote: > Following code will freeze app on std.gc.fullCollect(), when sqlite3_close() > in destructor is called. If destructor is called manualy, everything goes ok. > > Is it a bug, and if is, with what? It behaves same on winxp64 and centos5.2 > using dmd 1.30 and sqlite 3.6.5 or 3.6.19 statically import lib. Libraries > are tested so I do not suspect problem lies in them (they are compiled with > dmc/gcc using full threading support). > > Is this some problem with GC or, more likely, my knowledge? I would > appreciate some clarification, this thing took me a lot of hours to track. > > Thanks, > Bane > > ========================================== > > > import std.stdio; > import std.gc; > import std.string; > import std.thread; > > pragma(lib, "sqlite3.lib"); > const int SQLITE_OK = 0; // Successful result. > struct sqlite3 {} > extern(C) int sqlite3_open (char* filename, sqlite3** database); > extern(C) int sqlite3_close(sqlite3* database); > > class SQLite { > sqlite3* h; > this(){ > assert(sqlite3_open(toStringz(":memory:"), &h) == SQLITE_OK); > } > ~this(){ > writefln("~this start"); // to help debug > assert(sqlite3_close(h) == SQLITE_OK); > writefln("~this stop"); // to help debug > } > } > > class T : Thread { > int run(){ > SQLite s = new SQLite; > // if next line is uncommented then app wont freeze > // delete s; > return 0; > } > } > > void main(){ > while(true){ > T t = new T; > t.start; > writefln(Thread.nthreads); > if(Thread.nthreads > 10) > fullCollect; // this will freeze app > } > }