> hopefully there are better tools there for debugging this > type of thing.
There are, but usually they are not free. Quick googling for "valgrind for windows" brought up commercial products Purify and Insure++ and free product DUMA. I used Purify myself occasionally - it's not bad, but you have to buy it. You can try other products and see what it shows you. Pavel On Mon, Jun 21, 2010 at 11:16 AM, Sam Carleton <scarle...@miltonstreet.com> wrote: > On Mon, Jun 21, 2010 at 9:37 AM, Roger Binns <rog...@rogerbinns.com> wrote: > >> As an example you would experience something like this if SQLite got >> initialized during the config phase. Just to make things even more >> complicated ASLR is turned off if you have Wine installed under Linux so I >> was only seeing the problem on some machines. > > Roger, > > Your post bring me back to what I asked in my last post: > > On Sun, Jun 20, 2010 at 11:31 PM, Sam Carleton > <scarle...@miltonstreet.com> wrote: >> >> Through one request from the client, I open and close the database >> multiple times. Since everything is very module, I am taking that >> approach with the DB, too: For authentication it is open/closed, for >> the initialization of the request the db is open/closed, for the >> processing of the request, the db is opened and closed. All of these >> are using the one and only C++ class to open and close the db. This >> approach allows me to keep all the open's and closes VERY close >> together, there might be lots of code that gets called because of a >> function call in between, but the function that does the open, does >> the close. This is why I took this approach. Since there are >> different threads access the DB at the same time, could this approach >> be causing problems I am unaware of? Would I be better off switching >> over to an approach of: each request opens the DB once and uses the >> same connection through the whole request? > > My point is: I don't do ANYTHING db initialization in start up phase > of loading my module. In the documentation for sqlite3_initialize() > it says, "The sqlite3_initialize() routine is called internally by > many other SQLite interfaces so that an application usually does not > need to invoke sqlite3_initialize() directly." So the Apache module > never calls sqlite3_initialize() directly, it allows the first > sqlite3_open_v2() to call it. > > I also don't believe any of the reading of module parameters > (configuration stuff that happens both times Apache loads the module) > every uses the database, they are all reading in info from flat files > which are used when a request comes in, to connect to the database. > > Oh, and this error does *NOT* happen all the time... The first thing > the web browser does once it connects is start a slide show, so within > 5 seconds there is a new request coming in from each browser all the > time. I have to open browser, after browser, sometime it happens on > one of the requests from the first browser (normally not) or it > happens after opening a bunch of them. The the specific close in > which the crash happens is one of two places in the beginning of the > request, either in the authentication section or in the process of > initialization of the request object, which happens after > authentication. > > I would love to port this code to Linux, but... It is not stand > alone, it depends on a .Net WinForms app to do all the initialization > and configuration of the Apache web server, there are also a total of > 6 different project (one is the Apache module, the rest are Axis2/C > Web Services and library classes), there is some Window specific code > in the Axis2/C projects because Axis2/C doesn't have good file > support. The long and the short of it is, I think it would take me > about a month to port to Linux, just to find one bug? Not a good > investment of my time. I am hoping to port the whole thing to OSX > some time next year (which is why I am using SQLite and not SQL Server > Express), hopefully there are better tools there for debugging this > type of thing. > > Sam > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
