Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1754

Re: Problem with DragAnObject on RISC OS 6.20

Show all headers | View raw

In message <6dc02b81-c9ed-4034-90d7-671f3e804f98@n16g2000vbn.googlegroups.com>
 on 26 May 2012 Gerph  wrote:

> On May 26, 10:50 pm, Matthew Phillips <spam20...@yahoo.co.uk> wrote:
> > I've appended a typical back trace.  A function within Impact called
> > Drag_Object calls the SWI DragAnObject_Start (via a generic library
> > function called Swi) with a C function as the callback for rendering.
> >  The SWI is called via _kernel_swi.  While within that library function
> > an address exception occurs, which is passed to my signal handler which
> > spits out the back trace to a file.
> 
> That sounds like you've got a problem right there. Unless you really
> need it, stop using the signal handler and you'll get the Diagnostic
> Dump out of the system when the failure occurs.

On eof the users sent me the diagnostic dump file, but I expect the registers
and disassembly will relate to the exception being raised from within the
signal handler, whose main purpose is to capture the backtrace to a file. 
I'll compile a version without this and send it to one of the users to obtain
a better diagnostic.

> > In <dd968d15-13ad-4f4b-a736-74152f76d...@c26g2000vbq.googlegroups.com> (3
> > June 2011) James Lampard described a fault in DragAnObject which could
> > lead
> 
> They start by basing their description on the erroneous documentation
> from PRM 5a that states that the bit 17 controls whether the render
> function operation is called in USR mode or not (which is what they
> state). Bit 17 controls whether the C environment is set up for the
> module callback and has nothing to do with the code being called in
> USR mode. There probably should not be a USR mode entry sequence for
> this module in any case - I believe that this was a documentation
> error introduced between the author and the production of the updated
> PRMs.
> 
> > to stack overflows and aborts on 32-bit systems, which was fixed in
> > ROOL's DragAnObject 0.09.
> 
> The 'fix' they describe is unlikely to affect the code that was
> changed and in any case will cause breakages on earlier modules unless
> care is taken to ensure the version of the module, as no validation of
> the flags is made.

As I received the code, Impact called DragAnObjectStart with bit 17 set (so
the callback would be called in SVC mode according to the PRM, but in reality
set up for module callback, which doesn't seem right to me, given we are
calling from an application).

In April 2011 I changed the code so that bit 17 was clear.  This was because
I had discovered Impact crashed on RISC OS 4.02 when dragging an object.  The
rendering procedure called setjmp, but not longjmp, but this was enough to
provoke the crash.  The bit 17 value was probably a red herring but it looked
wrong to me so I tidied it up at the same time.

In May 2011 a user reported the problem of the crash on RISC OS 6.20, but
owing to a misunderstanding I thought some other corrections fixed it.  There
was also, independently, a problem running Impact on the A9, where the Shared
C Library setjmp/longjmp does not work.  This gave rise to the thread I
quoted from, where James Lampard replied regarding the changes on the RISC OS
5 fork.  As a result of that, and a posting from Martin Wuerthner, I changed
my DragAnObject_Start call to have bit 17 clear and bit 18 set, and that's
how things are at the moment.

> If bit 17 is set:
> 
> R0-R3 are updated from the parameter block from R2.
> R10 contains the SVC stack limit
> R13 is the SVC stack
> You are in SVC mode.
> IRQ state has been preserved.
> 
> If bit 17 is clear:
> 
> R0-R3 are set up from the parameter block from R2.
> R10 contains 0 (stack limit checking may be a problem for C
> applications).
> R13 is the SVC stack
> You are in SVC mode.
> IRQ state has been preserved.
> 
> As you can see the sequence is very similar.

If you have bit 17 set, we have the SVC stack limit in R10, but does that
make stack limit checking better for C applications, as opposed to C modules? 
If so, I cannot see why you would want to call with bit 17 clear.

> > I have found a problem (on RISC OS 4.02, but not on 5.16, not tested on
> > others) where using setjmp and longjmp within the rendering callback code
> > caused a crash, so I had to trap errors in other ways.
> 
> Yeah, don't do that.
> You do not have a USR mode C environment in the render callback and
> should not do any calls like that. Because you don't have a C
> environment set up, you shouldn't rely on any of the operations within
> the callback function working in C environment. You may have luck
> using the SVC C-module form of entry sequence, but I wouldn't
> guarantee it.
> 
> And NEVER longjmp out of the render function.

There are various places where the rendering function might attempt to use
longjmp to get out, but that will only be if there are errors in SWIs and as
far as I know there will not be in these cases.  I removed the only
use of setjmp a year ago.  Obviously I ought to correct these calls and
handle SWI errors differently if the function is used by a render callback,
and there may be some obscure reason why one of the SWIs is giving rise to an
error on RISC OS 6.20 but not on any other version, I suppose.

The rendering function does call quite a few other functions to get its work
done: they are nested up to six deep, and the automatic variables involved
require a maximum of 47 words in the worst case.  The SWIs which are called
include Hourglass_On and Hourglass_Off, Wimp_PlotIcon, Font_FindFont,
Font_Paint, OS_Plot, and a few things to set colours.  As for C Library
functions there are memset and strlen which should be innocuous, and bsearch
which I don't suppose requires much stack.

From what you write above, about not relying on the C environment, it sounds
like I could be in trouble with the amount of stack needed.  If that's the
case I may have to rewrite to output to a sprite and use DragASprite rather
than DragAnObject, which would be a nuisance.

Or maybe I just ought to switch back to having bit 17 set.

I'll try to get a better backtrace from BTSDump and see if that tells me
anything.

Thanks,

-- 
Matthew Phillips
Durham

Back to comp.sys.acorn.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Problem with DragAnObject on RISC OS 6.20 Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-05-26 22:50 +0100
  Re: Problem with DragAnObject on RISC OS 6.20 Steve Fryatt <news@stevefryatt.org.uk> - 2012-05-26 23:15 +0100
  Re: Problem with DragAnObject on RISC OS 6.20 Gerph <gerph@gerph.org> - 2012-05-26 15:59 -0700
    Re: Problem with DragAnObject on RISC OS 6.20 Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-05-28 08:42 +0100
      Re: Problem with DragAnObject on RISC OS 6.20 Gerph <gerph@gerph.org> - 2012-05-28 12:00 -0700
        Re: Problem with DragAnObject on RISC OS 6.20 Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-05-28 23:39 +0100
        Re: Problem with DragAnObject on RISC OS 6.20 Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-05-28 23:54 +0100
          Re: Problem with DragAnObject on RISC OS 6.20 Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-06-08 00:35 +0100
            Re: Problem with DragAnObject on RISC OS 6.20 Gerph <gerph@gerph.org> - 2012-06-12 13:18 -0700

csiph-web