Re: Thread exiting with code 1282 (0x502)

#define DIM(x) ( sizeof(x) / sizeof((x)[0])

replace sizeof() with DIM() for all situations in which it applies to an array of
characters. Note thst there are often lots of instances of sizeof() in code that do not
have anything to do with character arrays and these would not be replaced
joe

On Wed, 7 Feb 2007 17:37:11 -0500, "Patricio" <Patricio@xxxxxxxxxxxxxxxxx> wrote:

Ok... basic stuff. The call

GetWindowText(pTTT->szText, sizeof(pTTT->szText));

should be

GetWindowText(pTTT->szText, sizeof(pTTT->szText) /
sizeof(pTTT->szText[0]));

This problem is all over the code... major find/replace to do...

Any recommendations to make that method better are welcome.

Thank you,
Patricio.

"Patricio" <Patricio@xxxxxxxxxxxxxxxxx> wrote in message
news:28C0B8C3-097B-4232-8F5B-8DA63A1D053B@xxxxxxxxxxxxxxxx
Hello Joe,

Thank you for your answers. While I was writing back to Charles and
trying things I discover the crash came from the following method:

BOOL CSimpleLineDlg::OnToolTipNotify(UINT, NMHDR* pNMHDR, LRESULT*)
{
TOOLTIPTEXT *pTTT = (TOOLTIPTEXT *)pNMHDR;
UINT nID = pNMHDR->idFrom;

if (pTTT->uFlags & TTF_IDISHWND)
{
// idFrom is actually the HWND of the tool
nID = ::GetDlgCtrlID((HWND)nID);

if(nID)
{
CWnd * pWnd = (CWnd *)GetDlgItem(nID);
pWnd->GetWindowText(pTTT->szText, sizeof(pTTT->szText));
pTTT->hinst = AfxGetResourceHandle();
return(TRUE);
}
}

return(FALSE);
}

The size of pTTT->szText is 80 so that should be the issue, but the
GetWindowText() method should handle that.

Maybe this implementation is not the correct one but to me it looks simple
enough. I am not an MFC programmer so this code actually causes me
physical pain :-) (specially now that I work with C#).

Thank you again,
Patricio.


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:qhbks2tv6l1q19t9qnre0m7pp9cr5glu21@xxxxxxxxxx
See below...
On Wed, 7 Feb 2007 14:07:23 -0500, "Patricio"
<Patricio@xxxxxxxxxxxxxxxxx> wrote:

Hello Joe,

Thank you for your answer. I do have the exception trapping enabled for
all
exceptions but the application just exits. I am not creating any
threads.
***
But someone might be. There are several DLLs and such that have the
potential for
creating threads you don't know about
****
The crash happens when there is a dialog open that have some editable
text
boxes with very large strings. I suspect the threads come from the
dialog.
****
No. Unless you wrote code in your dialog to create threads, no threads
are created to run
a dialog; it runs in the main GUI thread
****

This software it is a huge legacy MFC application that we have to
maintain
and hopefully it will be in C# next year. I could not find the
ExitProcess/ExitThread on the code so that I don't know how to setup the
breakpoint.
****
There's no code to find. I'm talking about setting a breakpoint on the
API entry point.
****
Will those method be in the MFC DLLs? What else can I try?
****
What I find odd is that the threads AND the app both exit with the same
exit code. It
seems too strong a relationship to be an accident. But given it is a
large legacy app,
who knows what coding blunders have been committed...that's why, if you
can set a
breakpoint at the API entry points and get a call trace, you might find
some lurking code
that did exit(0) or something else grossly irresponsible somewhere in the
mass of code or
in some DLL.

The CodeBase system was notorious for this; I hope in the years since I
was an unfortunate
victim<<<<<customer<<<<<<<<pre-alpha tester of what was laughingly called
a "product" that
they have fixed these defects.
joe

*****

Thank you,
Patricio.


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:ednis2dsrn7q6s5krf3cdsirq31j2p9e60@xxxxxxxxxx
You might try setting a breakpoint at ExitThread as a start. It may
not
tell you much,
but it may also tell you a great deal. Look at the call stack. You
might
enable
exception trapping on the thread (under the Debug menu, Exceptions...).
Just because no
exception is displayed does not prove one is not happening; it merely
means that no one is
reporting it. If there is a try/except or try/catch mechanism that
catches the exception,
it may not be reported.

It appears there is a mixture of managed and native code; this
introduces
a massive number
of possibilities for things going wrong.

Also try a breakpoint at ExitProcess.
joe

On Tue, 6 Feb 2007 14:44:54 -0500, "Patricio"
<Patricio@xxxxxxxxxxxxxxxxx>
wrote:

Hello,

I have an MFC application that started exiting with exit code 1282
(0x502).
The exact message is:

The thread 'Win32 Thread' (0x1848) has exited with code 1282 (0x502).
The thread 'Win32 Thread' (0x1c50) has exited with code 1282 (0x502).
The thread 'Win32 Thread' (0x1c90) has exited with code 1282 (0x502).
The program '[7608] <...>.exe: Managed' has exited with code 1282
(0x502).
The program '[7608] <...>.exe: Native' has exited with code 1282
(0x502).

There are no exceptions, the application just dissappears. This
started
to
happen when some strings started to become very large so that I suspect
of
some buffer overrun somewhere.

Was does it means the error code 1282 (0x502)? I could not find it.

How do I debug an MFC application that is crashing in this way?

Thank you,
Patricio.


Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Thread exiting with code 1282 (0x502)
    ... Whenever you use sizeofof a text buffer it must ALWAYS be coded as ... I'm talking about setting a breakpoint on the ... exception trapping on the thread ... I have an MFC application that started exiting with exit code 1282 ...
    (microsoft.public.vc.mfc)
  • Re: Thread exiting with code 1282 (0x502)
    ... I am not an MFC programmer so this code actually causes me physical pain :-). ... I'm talking about setting a breakpoint on the API entry point. ... What I find odd is that the threads AND the app both exit with the same exit code. ... exception trapping on the thread ...
    (microsoft.public.vc.mfc)
  • Re: Thread exiting with code 1282 (0x502)
    ... I am not an MFC programmer so this code actually causes me physical pain :-). ... I'm talking about setting a breakpoint on the API entry point. ... What I find odd is that the threads AND the app both exit with the same exit code. ... exception trapping on the thread ...
    (microsoft.public.vc.mfc)
  • Re: Thread exiting with code 1282 (0x502)
    ... You might try setting a breakpoint at ExitThread as a start. ... exception trapping on the thread ... reporting it. ... I have an MFC application that started exiting with exit code 1282. ...
    (microsoft.public.vc.mfc)
  • Re: Exception Handling issue
    ... > The system calls your DialogProc within it's own try/except block. ... executed after the exception line, since the system "throws me out of the ... If NOT using MFC i don't get the exeption if i ...
    (microsoft.public.windowsce.embedded.vc)