Re: FW: Help debugging a problem!
On Wed, 28 Sep 2005 23:53:28 +0100, you wrote: >I've tried the following > >1. Use DebugBreak before and after the RegisterClassEx16 call with no temp >defined >- Stacks are identical as far as winedbg traces (0x60 bytes) Hi Jason, This winedbg stack trace (info stack) is equivalent to the examine command: x /24x $esp (24 words == 0x60 bytes). Change the repeat count from 24 to what you want. If there is a stack corruption, this way you can find out where and then you can add a watch point on it. Rein.
Re: FW: Help debugging a problem!
On Wed, Sep 28, 2005 at 11:53:28PM +0100, Ann & Jason Edmeades wrote:
> Ok, more information...
>
> The routine (slightly modified to allow code before the return) is
>
> ATOM WINAPI RegisterClass16( const WNDCLASS16 *wc )
> {
> WNDCLASSEX16 wcex;
> ATOM fred;
>
> wcex.cbSize= sizeof(wcex);
> :
> fred = RegisterClassEx16( &wcex );
> return fred;
> }
>
> Advice please Anyone...
I think the passed class has "cbClsExtra" extrabytes set and used.
In this case you need to allocate more bytes then just WNDCLASSEX16 and
also copy the extra bytes.
So I guess this function is broken a bit.
This is just a guess, I might be wrong.
Ciao, Marcus
Re: FW: Help debugging a problem!
On 9/28/05, Ann & Jason Edmeades <[EMAIL PROTECTED]> wrote: > > Adding inchar temp[8]; before the WNDCLASSEX16 and it still fails > Adding inchar temp[9]; and the program starts working... > Adding inchar temp[9]; after the WNDCLASSEX16 and it still fails > (Yes, temp is unused...) > > So that would agree heap corruption of some sort > Stack corruption :) > > Next question... how to pin this down. > You can try the method of commenting out large portions of the called code, then sequentially uncommenting function calls. Also, look for variables allocated on the stack (especially strings or arrays) and make sure they never get overwritten. > I've tried the following > > 2. Initialize temp to 0x00's (still works @ 9 and fails @ 8). Then adding an > 'if' statement before the return to query the bytes... > a. If I put a stream of if statements it always works > I wouldn't try this route, adding stack vars or printfs and seeing what makes it not crash that way. The hard thing about stack or heap corruption is that it's seemingly random and can crash at any point (more or less). I would focus on finding which variable is being overwritten. -- James Hawkins
FW: Help debugging a problem!
Ok, more information...
The routine (slightly modified to allow code before the return) is
ATOM WINAPI RegisterClass16( const WNDCLASS16 *wc )
{
WNDCLASSEX16 wcex;
ATOM fred;
wcex.cbSize= sizeof(wcex);
:
fred = RegisterClassEx16( &wcex );
return fred;
}
This fails for the application as it stands.
Adding inchar temp[8]; before the WNDCLASSEX16 and it still fails
Adding inchar temp[9]; and the program starts working...
Adding inchar temp[9]; after the WNDCLASSEX16 and it still fails
(Yes, temp is unused...)
So that would agree heap corruption of some sort
Next question... how to pin this down.
I've tried the following
1. Use DebugBreak before and after the RegisterClassEx16 call with no temp
defined
- Stacks are identical as far as winedbg traces (0x60 bytes)
- registers are nearly identical, only difference is ESI after
2. Initialize temp to 0x00's (still works @ 9 and fails @ 8). Then adding an
'if' statement before the return to query the bytes...
a. If I put a stream of if statements it always works
b. If I put a single statement it [EMAIL PROTECTED] / [EMAIL PROTECTED]
Manually, I have
confirmed chars 0->11 are not touched (3 longs).
c. I changed temp to be 8192 in size, memset it to 0x00 and then post call
checked each byte to see if it had changed - it hadn't, they were all still
0x00
=> I don't think the actual values are important, size matters (so they
say!)
3. I recompiled user.c with -O0 and got different results.
With char temp; in it works, with it removed it fails!
4. I compared the assembler output produced with temp[8] and temp[9] and as
expected they are identical except for some offsets in that routine.
ARGH...
Advice please Anyone...
Jason
Re: Help debugging a problem!
James Hawkins wrote:
On 9/27/05, Ann & Jason Edmeades <[EMAIL PROTECTED]> wrote:
If I change this to
fred = RegisterClassEx16( &wcex );
TRACE("Here... %d\n", fred);
return fred;
it all works.!
This sounds like the stack is getting trashed.
I agree this looks very much like a stack corruption issue.
Ivan.
Re: Help debugging a problem!
On 9/27/05, James Hawkins <[EMAIL PROTECTED]> wrote:
> On 9/27/05, Ann & Jason Edmeades <[EMAIL PROTECTED]> wrote:
> >
> > If I change this to
> > fred = RegisterClassEx16( &wcex );
> > TRACE("Here... %d\n", fred);
> > return fred;
> >
> > it all works.!
> >
>
> This sounds like the stack is getting trashed.
I just read through your post again and saw that the app was hanging,
and by hanging I'm assuming it's stuck in the code somewhere, whereas
I thought the app was crashing. It might not be the case then that
the stack is getting trashed, though you can still use the debugging
technique mentioned.
--
James Hawkins
Re: Help debugging a problem!
On 9/27/05, Ann & Jason Edmeades <[EMAIL PROTECTED]> wrote:
>
> If I change this to
> fred = RegisterClassEx16( &wcex );
> TRACE("Here... %d\n", fred);
> return fred;
>
> it all works.!
>
This sounds like the stack is getting trashed. That is usually the
case when randomly added functions make it not crash. You want to
look for places where local variables (on the stack of course) are
being overwritten. A good example of this is copying a larger string
into a smaller local char array. When looking for a stack crasher, I
comment out huge sections of code until it doesn't crash anymore, and
then piece by piece uncomment the next function. For example,
void foo()
{
#if 0
a();
b();
c();
#endif
}
doesn't crash, but
void foo()
{
a();
#if 0
b();
c();
#endif
}
does crash, then your culprit is in a(). Then you recurse into a()
and repeat the process all over again till you find the stack crasher.
--
James Hawkins
Help debugging a problem!
Hiya,
I've got a weird issue and was wondering if anyone could advise on how to
resolve. (Comes from a 16bit windows app, but is a more general debugging
issue).
The problem is ...
1) If I run the application, it just hangs - no overly helpful information
at all.
2) If I add WINEDEBUG +relay trace, it runs ok :-) (Workaround...!)
3) If I add anything else on WINEDEBUG other than relay, it fails
4) Running under winedbg didn't help at all - I could code to stop it before
the hang but it wouldn't step through to the failure
5) Attaching to the hung process shows code in 16 bit user app, and winedbg
didn't overly help there either
So - I've (painstakingly) got to the point of failure with the add of debug
tracepoints and comparing the relay with the debug statements.
Now the odd bit!
If you look at dlls\user\wnd16.c, routine RegisterClass16 the final line is:
return RegisterClassEx16( &wcex );
If I change this to
fred = RegisterClassEx16( &wcex );
TRACE("Here... %d\n", fred);
return fred;
it all works.!
How can I debug this further? I was thinking about trying to dump the
registers before and after the trace statement, but I really can't think of
what could be causing the problem!
Does windows guarantee any of the registers across a win16 call which we
don't honour? What about i386 flags?
Any suggestions please?
Jason
