1. Strange crash
I've been having this really strange crash, which I can't explain. It's in
a function that's used as a callback for an ActiveX control. It crashes on
this line (machine exception):
rect[3..4] += rect[1..2]
but only in certain places:
function IOleInPlaceSite_GetWindowContext( atom this, atom ppFrame,
atom ppDoc, atom lprcPosRect, atom lprcClipRect, atom lpFrameInfo )
sequence rect
integer obj_ix
atom pframe
obj_ix = get_obj_from_this( this )
if not obj_ix then
poke4( ppFrame, 0 )
poke4( ppDoc, 0 )
poke4( lprcPosRect, repeat(0, 4 ) )
poke4( lprcClipRect, repeat( 0, 4 ) )
poke4( lpFrameInfo, repeat( 0, 5 ) )
-- E_UNEXPECTED
return #800FFFF
end if
rect = obj_table[OBJ_POS][obj_ix]
-- ************************************************
-- WORKS OK HERE
rect[3..4] += rect[1..2]
-- ************************************************
-- supply the pointer to IOleInPlaceFrame
pframe = find( IOleInPlaceFrame_b, interface_table[I_BYTES] )
pframe = interface_table[I_THIS][pframe]
poke4( ppFrame, pframe )
-- ************************************************
-- CRASHES HERE
--rect[3..4] += rect[1..2]
-- ************************************************
poke4( lprcPosRect, rect )
poke4( lprcClipRect, rect )
-- Fill OLEINPLACEFRAME
poke4( lpFrameInfo, { 20, 0, obj_table[OBJ_PARENT][obj_ix],
0, 0 } )
return 0
end function
I haven't been able to duplicate this elsewhere, but it reminds me of
something where win32lib crashes if you call allocate before creating
controls (at least it did at one point). Has anyone else ever seen this?
Have any ideas about what's causing it? Oh, I can also stop the crash by
changing the line to
rect[3] += rect[1]
rect[4] += rect[2]
or printing or somehow referring to rect differently, or simply opening up
the trace window. It's like it didn't properly allocate space correctly or
something.
Matt Lewis
2. Re: Strange crash
Relnotes for 2.3 :
bug fix - Linux Interpreter: programs of more than a few thousand lines had a
chance
(maybe 20%) of having one of their statements crash whenever it was executed.
perhaps there's one more such bug in exw? Or it is some random memory corruption
in your program that shows many lines after it is done? (Oh, this reminds me
placing check numbers around structs in C...)
Martin
----- Original Message -----
From: "Phil Russell" <pg_russell at lineone.net>
To: "EUforum" <EUforum at topica.com>
Subject: RE: Strange crash
>
> Matt,
>
> A while ago I got a similar error with the line:
>
> GridTopRow[grid] -= GridDraw[grid][MAX_VISIBLE_ROWS]
>
> This gave me a page fault when processing a WM_VSCROLL on Win95 (but not
> on 98 or 2K). It went away when I amended it to:
>
> GridTopRow[grid] -= 0
> GridTopRow[grid] -= GridDraw[grid][MAX_VISIBLE_ROWS]
>
> Similar assignments elsewhere in the code worked absolutely fine.
> Absolutely no idea why, though...
>
> Regards,
>
> Phil Russell
>
>
> Matthew Lewis wrote:
> >
> > I've been having this really strange crash, which I can't explain. It's
> > in
> > a function that's used as a callback for an ActiveX control. It crashes
> > on
> > this line (machine exception):
> >
> > rect[3..4] += rect[1..2]
> >
>
>
>
>
3. Re: Strange crash
Matt Lewis writes:
> Have any ideas about what's causing it? Oh, I can also stop the crash by
> changing the line to
>
> rect[3] += rect[1]
> rect[4] += rect[2]
There aren't any known bugs in the
Euphoria interpreter run-time engine for 2.3.
The subscript statements above won't allocate any memory.
When you instead use a slice, memory might be allocated from
the heap. If the heap has been corrupted by earlier poke/poke4 etc.
statements, then a crash could happen.
I would very carefully check all the addresses that were passed in to
your routine, and all the pokes, making sure that enough memory
has been allocated in each case, and you aren't writing out-of-bounds.
Then I would look at any pokes etc that you did before the routine
was called. Be sure to use trace(3).
Memory corruption bugs can be a nightmare to solve.
The slightest change to your program can make the
bug appear or disappear. People end up believing
all sorts of superstitions - "the bug only happens on Tuesdays
when it's raining!". You shouldn't assume that the line it
crashes on is buggy. About all you can say is that the corruption
happened before this point.
It's too bad that euphoria\include\safe.e can't be used with Win32Lib.
I think it would be an excellent project for someone to
adapt safe.e to work with Win32Lib's storage allocator.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Strange crash
I have actually got a "safe" version of the memory allocation routines which I
use internally. I
will make it available ASAP.
13/09/2002 5:20:30 AM, Robert Craig <rds at RapidEuphoria.com> wrote:
>
>Matt Lewis writes:
>> Have any ideas about what's causing it? Oh, I can also stop the crash by
>> changing the line to
>>
>> rect[3] += rect[1]
>> rect[4] += rect[2]
>
>There aren't any known bugs in the
>Euphoria interpreter run-time engine for 2.3.
>
>The subscript statements above won't allocate any memory.
>When you instead use a slice, memory might be allocated from
>the heap. If the heap has been corrupted by earlier poke/poke4 etc.
>statements, then a crash could happen.
>
>I would very carefully check all the addresses that were passed in to
>your routine, and all the pokes, making sure that enough memory
>has been allocated in each case, and you aren't writing out-of-bounds.
>Then I would look at any pokes etc that you did before the routine
>was called. Be sure to use trace(3).
>
>Memory corruption bugs can be a nightmare to solve.
>The slightest change to your program can make the
>bug appear or disappear. People end up believing
>all sorts of superstitions - "the bug only happens on Tuesdays
>when it's raining!". You shouldn't assume that the line it
>crashes on is buggy. About all you can say is that the corruption
>happened before this point.
>
>It's too bad that euphoria\include\safe.e can't be used with Win32Lib.
>I think it would be an excellent project for someone to
>adapt safe.e to work with Win32Lib's storage allocator.
>
>Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
>
>
---------
Cheers,
Derek Parnell
ICQ# 7647806
