> You are great! > This is really possible in this case. > The application runs as a daemon and closes all file handles at startup. > > Now I need to check what this library is doing
One of quick solutions to this (without examining library) is to reopen std* handles to point to /dev/null, so that you protect yourself from these issues. But if you need those logs your library is writing then you still need to examine it to understand how to force it to write to some specific file. Pavel On Mon, Dec 20, 2010 at 12:55 PM, Michael Steiger <msli...@infoworks.at> wrote: > Hi Pavel! > > On 20.12.2010 15:36 Pavel Ivanov said the following: >>>>> Can you tell us what is producing that log text you found ? >>>> I am developing network appliances using EZchip network processors and >>>> for implementing some backend code I recently switched to SQLite. >>> >>> Mmm. Well, it could be overwriting some of your memory, or overwriting the >>> filespace. My bet is memory. Or it's possible you've found a bug in >>> SQLite where it writes the wrong memory to the file, I suppose. Perhaps >>> lint, clang, or something like them would spot the problem. Good luck. >> >> There's also another possibility that library writing logs do that >> unconditionally to stdout/stderr, i.e. to file handles 1 or 2. But if >> you for some reason close those handles next call to sqlite3_open will >> use them for database file. So in this case library will write >> straight into your database without knowing about that. > > You are great! > This is really possible in this case. > The application runs as a daemon and closes all file handles at startup. > > Now I need to check what this library is doing > > Many thanks > Michael > > > >> On Mon, Dec 20, 2010 at 7:58 AM, Simon Slavin<slav...@bigfraud.org> wrote: >>> >>> On 20 Dec 2010, at 12:49pm, Michael Steiger wrote: >>> >>>>> Can you tell us what is producing that log text you found ? >>>> I am developing network appliances using EZchip network processors and >>>> for implementing some backend code I recently switched to SQLite. >>> >>> Mmm. Well, it could be overwriting some of your memory, or overwriting the >>> filespace. My bet is memory. Or it's possible you've found a bug in >>> SQLite where it writes the wrong memory to the file, I suppose. Perhaps >>> lint, clang, or something like them would spot the problem. Good luck. >>> >>> Simon. > _______________________________________________ > 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
