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

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

Problem with longjmp on A9

Show all headers | View raw

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?

I'm not very familiar with the A9: would it be possible (or indeed advisable)
to softload a different version of the Shared C Library?

One thing I cannot do is rewrite the application to avoid using longjmp as
it's used extensively, systematically and (on other systems) completely
successfully for exception handling.

-- 
Matthew Phillips
Durham

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

Thread

Problem with longjmp on A9 Matthew Phillips <spam2011m@yahoo.co.uk> - 2011-07-09 07:31 +0100
  Re: Problem with longjmp on A9 wpb <willblatchley@yahoo.com> - 2011-07-10 21:20 -0700
    Re: Problem with longjmp on A9 David Pitt <pittdj@pittdj.co.uk> - 2011-07-11 07:28 +0100
  Re: Problem with longjmp on A9 Martin Wuerthner <spamtrap@mw-software.com> - 2011-07-11 11:39 +0200
    Re: Problem with longjmp on A9 David Pitt <pittdj@pittdj.co.uk> - 2011-07-12 07:23 +0100
      Re: Problem with longjmp on A9 Matthew Phillips <spam2011m@yahoo.co.uk> - 2011-07-12 21:15 +0100

csiph-web