Re: WM_TIMER crash (maybe)?
- From: "Alexander Grigoriev" <alegr@xxxxxxxxxxxxx>
- Date: Wed, 15 Jun 2005 22:12:20 -0700
Check that all your message handlers have EXACT number of arguments that's
required. Check that your ON_MESSAGE handlers have WPARAM and LPARAM
arguments, and ON_WM_TIMER handler has one argument.
In VC6, message map macros didn't check the handlers for the correct
signature. As a result, if a wrong handler is supplied, the message
dispatching function will crash if it gets another posted message
immediately after a message with an incorrect handler..
"x" <x@xxxxx> wrote in message news:ReadnTcATsuJzi3fRVn-oQ@xxxxxxxxxxxxxx
> running in debug / release?
> Stops with either release or debug mode (built & tested both).
>
>>What debug error?
> In a previous thread I described the situation as "program gone" in that
> it
> never displays any error message. A reply explained that if the dialog
> describing the fault is followed by a 2nd, the program is closed.
> DrWatson
> stack trace seems to indicate that this is happening, so one of my basic
> difficulties is in not having any info on the error.
>
> I've created a capability to insert a function with a text argument that
> sends the text to another task which maintains a forever circular queue of
> the text. Should the main program "be gone" I can examine the text log
> from
> what I call the TRACE task. I log every socket create, connect, send,
> receive, and close. I also log OnTimer entrance, exit, OnReceive
> entrance,
> exit, etc., along with about a thousand other points. What I always see
> as
> the last operations started with an OnReceive of a reply, processing,
> script
> execution (the program is programmable) leading up through sending of the
> next poll, and concludes with what looks to be a completely normal exit.
> Whatever the fault is it doesn't appear to be within the time-span of my
> program operation. I increased the frequency of WM_TIMER events
> (shortened
> the settimer) so I typically see one or more OnTimer executions after
> sending a message before the next OnReceive event. Since the log never
> ends
> on an OnTimer, I can only infer that the initiation of a next WM_TIMER
> event
> faults before my program reaches the first text TRACE from the OnTimer
> routine (practically the first thing my routine does).
>
>>What do you do on OnTimer overrides?
> The main function is to test if it's been too long since the last message
> was sent without having received an OnReceive event. Typically OnReceive
> events receive responses and initiate resuming the polling script. When
> OnTimer determines that a timeout has occurred, OnTimer initiates resuming
> the polling script. The polling script is operated in a separate thread.
> The TRACE log has always indicates correct response from the previous sent
> poll initiating the events resulting in the send event which ends the
> TRACE.
>
>>Ensure you are not creating tens of thousands of new sockets and not
> closing and deleting them after.
> The polling script is single threaded. It only uses a single socket.
>
> "Mark Randall" <markyr@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:eNko9UZcFHA.3464@xxxxxxxxxxxxxxxxxxxxxxx
> What debug error? Are they all running in debug / release? In release
> things
> like buffer overflows go unnoticed etc. Ensure you are not creating tens
> of
> thousands of new sockets and not closing and deleting them after.
>
> WM itself can't crash, its simply pushed through a handler array which if
> it
> works once, should work forever. What do you do on OnTimer overrides?
>
> --
> - Mark Randall
> http://zetech.swehli.com
>
> "x" <x@xxxxx> wrote in message news:5p-dnS7YCuKPXzLfRVn-jA@xxxxxxxxxxxxxx
>> I've got a network polling program. Interrogates different devices
>> continuously using CAsyncSockets. Use callbacks (OnReceive & OnConnect)
>> for
>> socket events, and keep WM_TIMER running to monitor when to give up for
>> response after send. After perhaps 100,000 transactions over anywhere
>> from
>> 8 to 24hrs the next OnTimer doesn't happen. An exception occurs when I
>> anticipate the next WM_TIMER should fire, the debug dialog opens, then
>> another exception occurs, and the program is closed. DrWatson only
>> records
>> the software Int that closest the program (trying to re-open debug dialog
>> when debug dialog is already opened).
>>
>> The program runs FOREVER without ever halting on any machine with VC
>> installed (can run weeks on end). If I install VC on a machine where I
>> see
>> the fault, I don't see the fault ever occur again (so much for using a
>> debugger). Depends shows all files present. I've taken to building with
>> release build with static libraries to minimize the requirements for any
>> external mfc dlls, but that doesn't have impact (a previous suggestion
>> from
>> this newsgroup was to check that all required dlls were current on a
>> machine
>> without VC installed).
>>
>> Since I'm unable to ever see the fault occur running under VC debugger, I
>> send diagnostics to another task so I can examine what was happening up
>> to
>> the fault. I see a socket created, connected, send, and return ... to
>> await
>> reply. There's no indication of another WM_TIMER event (OnTimer calls
>> are
>> set to reoccur repeatedly). Every fault seems to show a successful exit
>> of
>> all events through the last message sent, so I'm wondering if WM_TIMER is
>> crashing.
>>
>> Any ideas?
>>
>> Rich
>>
>>
>
>
>
.
- References:
- WM_TIMER crash (maybe)?
- From: x
- Re: WM_TIMER crash (maybe)?
- From: Mark Randall
- Re: WM_TIMER crash (maybe)?
- From: x
- WM_TIMER crash (maybe)?
- Prev by Date: Re: How to get proper tab sequence to controls
- Next by Date: Re: How to get proper tab sequence to controls
- Previous by thread: Re: WM_TIMER crash (maybe)?
- Next by thread: Re: WM_TIMER crash (maybe)?
- Index(es):
Relevant Pages
|
