@ Jay:
So those two functions are in separate processes, and in the start of each
of them, I am creating a new database handle, which both open with return
value of 0, and close with return value of 0 - they aren't actually sharing
anything except the database file itself, but for which they each have their
own unique handles.
@ Dennis:
Yeah my LPARAM and WPARAM are just 0, I know sending pointers through could
be disastrous. So I checked those are both just 0 for now. The posted
message contains no other data, it's just meant to be a signal to my app to
go ahead and do some stuff. I'm running my application through VC++ .NET, so
when I exit the application, it just dumps all those memory leaks. Of course
the memory leaks only happen in this post message instance, not elsewhere
where I make heavy use of the database, and threads! My dumps come out in
trace statements in the debugger. Maybe I could get more info if it told me
where the leaks were occurring, specifically in the sqlite code itself, so
I'll try setting those Crt flags to hopefully get more information. The
other thing I did was close the database handle in app #2 before it uses
PostMessage() - then there are no memory leaks. But opening and closing the
database everytime I have to post a message may be too burdensome,
Thank you!
On 9/15/05, Dennis Jenkins <[EMAIL PROTECTED]> wrote:
>
> Mark Wyszomierski wrote:
>
> > app1:
> >SomeThread()
> >{
> > sqlite3 *db = opendatabase();
> > writesomestuff();
> > PostMessage(my_other_app, 0, 0);
> > closedatabase(db);
> > return 0;
> >}
> > app2:
> >MessageHandlerInMainThread()
> >{
> > sqlite3 *db = opendatabase();
> > ReadDatabaseStuff(db);
> > closedatabase();
> > return 0;
> >}
> > Thanks!
> >Mark
> >
> >
>
> hmmm... that should work. Since in your message LPARAM and WPARAM are
> 0, I assume that they convey no pointers to memory buffers. Does the
> posted message contain any data other than the message id?
>
> (From memory) If you use "SendMessage" to send a message to a window
> owned by a different process, then it will behave like PostMessage, but
> block until the other process has dispatched your message. Let me check
> the MSDN real quick...
>
> Oops. It looks like what I posted earlier was in error. From the Feb
> 2003 platform SDK on "SendMessage":
>
> Applications that need to communicate using HWND_BROADCAST should
> use the RegisterWindowMessage function to obtain a unique message
> for inter-application communication.
>
> The system only does marshalling for system messages (those in the
> range 0 to WM_USER). To send other messages (those above *WM_USER*)
> to another process, you must do custom marshalling.
>
> If the specified window was created by the calling thread, the
> window procedure is called immediately as a subroutine. If the
> specified window was created by a different thread, the system
> switches to that thread and calls the appropriate window procedure.
> Messages sent between threads are processed only when the receiving
> thread executes message retrieval code. The sending thread is
> blocked until the receiving thread processes the message. However,
> the sending thread will process incoming nonqueued messages while
> waiting for its message to be processed. To prevent this, use
> SendMessageTimeout with SMTO_BLOCK set. For more information on
> nonqueued messages, see Nonqueued Messages.
>
>
> I'm at a loss right now. I supose that I'd need to learn more about
> your code.
>
>
> What mechanism are you using to track memory leaks? Many years ago I
> used "memcheck". It worked great, but the company (Stratosware) seems
> to be out of business now.
>
> I call this function first thing in my WinMain() to turn on the
> Microsoft run time library memory checking stuff:
> void SetDebugging(void)
> {
> // Turn on extream heap memory checking. This will slow down the
> system considerably.
>
>
> _CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF|_CRTDBG_ALLOC_MEM_DF|_CRTDBG_CHECK_ALWAYS_DF);
>
> _CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE );
> _CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE );
> _CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_FILE );
>
> _CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDERR );
> _CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDERR );
> _CrtSetReportFile( _CRT_ERROR, _CRTDBG_FILE_STDERR );
> }
>
> I also redirect stdout and stderr to a console created with
> "AllocConsole()".
> I assume that you do something similar?
>
>
