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

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

Re: Problem with DragAnObject on RISC OS 6.20

Show all headers | View raw

In message <b498a2ed-3973-49cd-b3a8-a53b6333a2eb@q2g2000vbv.googlegroups.com>
 on 28 May 2012 Gerph  wrote:

> On May 28, 8:42 am, Matthew Phillips <spam20...@yahoo.co.uk> wrote:
> > 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.
>
> A few people reported this, but nobody supplied a test case that I could
> use to reproduce the problem. Aside from the screwy way that CTL mangled
> the jmpbuf, I couldn't see anything else that would cause problems... not
> to say that there aren't problems, but just that I could never reproduce
> them. That said, the version of the OS on the A9 compared to the rest of
> the system was significantly older.

Here's what I said on this group on 9 July 2011:

I have been trying to track down a difficult bug in my software which only
affects users of the A9Home computer, specifically an A9 running "RISC OS
Select 4.42 kernel 8.68".  The Shared C Library version is "5.59 (04 Mar
2006) 32bit only".  The same user has a RISC PC with Select 6.10 kernel 10.49
and Shared C Library "5.63 (11 Mar 2007) 26bit only" on which the problem
does not occur.  It does not occur on the Iyonix or Beagleboard either.

After investigating, I can only conclude that the A9's Shared C Library is
not fully restoring the context saved at setjmp when a subsequent longjmp is
executed.  Let me set out my reasoning and if anyone finds any holes in it,
please let me know.

The problem occurs in a function which I can boil down to the following:

static void ExecuteFile( action a, dbase d, card c, char *path, int context )
{
    execstr e;
    int f;

    e.path     = M_StoreString( path );
    e.a        = a;
    e.line     = 0;

    f = FC_ReadFile( path );

    if ( !setjmp(E_GetJumpBuffer()) )
    {
        ExecuteBlock( &e, d, c, f, FALSE );
    }

    M_FreeMemory( e.path );
    E_UnSetErrorPath();
    if ( f )   FC_CloseFile( f );
}

The integer f is set to a RISC OS file handle returned by the function
FC_ReadFile.  The E_GetJumpBuffer() returns a jmp_buf for use by setjmp, and
E_UnSetErrorPath unallocates it again.

The function works fine if the ExecuteBlock function is exited normally, but
if it is exited using longjmp then upon closing the file with FC_CloseFile it
turns out that f has somehow got corrupted and is equal to 618708.  The SWI
then gives the error that the filehandle is illegal or already closed.

As you can see, f is an automatic and its address is not passed to the inner
function.

I can make the error go away completely by changing the code so that we have
a global called DebugF declared as an int*:

static int *DebugF;

static void ExecuteFile( action a, dbase d, card c, char *path, int context )
{
    execstr e;
    int f;

    DebugF = &f;
... etc. as before.

When I examine the assembly language generated by the compiler in each case,
I find that in the version which produces the error f is stored throughout
the function in the register v5: it is never committed to memory.  In the
second version, because we have taken the address of f and stored it
somewhere, f is forced to be stored in memory.

So somehow, when longjmp is used, the value which has been placed in v5 is
not the value which was in f when setjmp was called.

There are three explanations for this that I can think of:

1) the implementation of longjmp on the A9 is flawed, and fails to restore v5
properly.

2) the implementation of setjmp on the A9 is flawed, and stores the wrong
value for v5.

3) some other part of my programme is stomping on the jmp_buf.

Normally of course any sane programmer would go for (3) as the most likely
explanation.  However, I have dumped the contents of the jmp_buf to file
immediately after the setjmp and on return from the longjmp and they are
identical.  So that rules out (3).  The structure of the jmp_buf is not
documented in public, but one of the words contains a value equal to the file
handle, f, so that suggests that longjmp is failing to restore v5, but only
on the A9.

Has anyone else had this sort of behaviour?  Are there any alternative
explanations before I take this up with ROL?

----------------

Martin Wuerthner confirmed that he had reported the problem to Advantage 6
and ROL in 2006 and that he regarded TechWriter and EasiWriter as beta
software on the A9 as a consequence.  As I did not have a very small test
case which provoked the problem, I did not take it any further, especially as
Martin confirmed that the problem seemed to have been resolved in later
versions of the ROL fork of the OS which had not yet been released for the
A9.

I concluded it was more a matter of lack of ongoing OS releases for the A9,
and as an A9 user was able to confirm that a softload of the Shared C
Library, as supplied with the C compiler, cured the problem, I have since
distributed that to the few people who use both Impact and the A9.

-- 
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