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

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

Problem with longjmp on A9

Back to article view | Back to comp.sys.acorn.programmer

Contents

  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

#532 — Problem with longjmp on A9

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

[toc] | [next] | [standalone]

#541

I can't be of much help, though I'd certainly be willing to run some
tests for you. The only thing that springs to mind is, is !Aemulor
running? I've experienced some weirdness in the past with the
SharedCLibrary that I've concluded might be to do with Aemulor...

[toc] | [prev] | [next] | [standalone]

#542

In message <5588672e-a708-43fa-aceb-70cbbc7a750c@n5g2000yqh.googlegrou 
ps.com>
  wpb <willblatchley@yahoo.com> wrote:

> I can't be of much help, though I'd certainly be willing to run some
> tests for you. The only thing that springs to mind is, is !Aemulor
> running? I've experienced some weirdness in the past with the
> SharedCLibrary that I've concluded might be to do with Aemulor...

I too can't be of much help with the original issue, being much more 
into BASIC than C, but I could run tests.

I do not have Aemulor on the A9home and am not aware of any 
SharedCLibrary wierdness.

Though the A9home has its beta issues the only genuine wierdness in 
the sense of never explained was the disc corruptions.

-- 
David Pitt

MessengerPro 6 on an ARMini running RISC OS 5

[toc] | [prev] | [next] | [standalone]

#543

In message <ac6ff5ef51.Matthew@sinenomine.freeserve.co.uk>
          Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

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

That is a known problem that I have reported to Ad6/ROL in 2006. 
longjmp is indeed broken on the current A9home ROM image (Select 4.42, 
CLib 5.59), but also on the previous A9home ROM image (which had CLib 
5.02).

That problem affects the exception handling in Easi/TechWriter and can 
lead to arbitrary failures of these applications on the A9home. That 
is the reason why I still advise users in the documentation that EW/TW 
has beta status on the A9home.

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

Yes, that should be possible. It was not an option in 2006 because 
there was no such version available for public distribution (the 
softload CLib for the Iyonix could not be used), but it should be easy 
enough nowadays to build a suitable CLib from the ROOL sources.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#546

In message <a0470ef151.martin@bach.planiverse.com>
  Martin Wuerthner <spamtrap@mw-software.com> wrote:

> In message <ac6ff5ef51.Matthew@sinenomine.freeserve.co.uk>
>           Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

[snip]

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

> Yes, that should be possible. It was not an option in 2006 because
> there was no such version available for public distribution (the
> softload CLib for the Iyonix could not be used), but it should be easy
> enough nowadays to build a suitable CLib from the ROOL sources.

I tried my luck on the A9home using the 32bit build of the 32bit CLib 
5.56, as supplied in the EndUser directory of the ROOL Tools, the one 
in Modules.500 that is. Using a test from Matthew the longjmp then 
landed in the right place.

-- 
David Pitt

MessengerPro 6 on an ARMini running RISC OS 5

[toc] | [prev] | [next] | [standalone]

#551

In message <5c3080f151.pittdj+@iyonix.home>
 on 12 Jul 2011 David Pitt  wrote:

> In message <a0470ef151.martin@bach.planiverse.com>
>   Martin Wuerthner <spamtrap@mw-software.com> wrote:
> 
> > In message <ac6ff5ef51.Matthew@sinenomine.freeserve.co.uk>
> >           Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
> 
> [snip]
> 
> >> 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?
> 
> > Yes, that should be possible. It was not an option in 2006 because
> > there was no such version available for public distribution (the
> > softload CLib for the Iyonix could not be used), but it should be easy
> > enough nowadays to build a suitable CLib from the ROOL sources.
> 
> I tried my luck on the A9home using the 32bit build of the 32bit CLib 
> 5.56, as supplied in the EndUser directory of the ROOL Tools, the one 
> in Modules.500 that is. Using a test from Matthew the longjmp then 
> landed in the right place.

Or more to the point, landed with the registers intact.  The longjmp was
going to the correct place, but with a register corrupted.

My test only exercised printf, fopen, fprintf and fclose, so it's not very
rigorous as far as detecting whether it is safe to run that version of the
Shared C Library on the A9.

You'd really need to load it and then run a selection of C-based applications
to give it a good test.  I don't know anything about how the Shared C Library
interacts with the rest of the OS, so I wouldn't like to suggest what things
might go wrong if it does prove to be incompatible.

It would be very interesting if the fix was as simple as loading this version
though.  Do please let us know what you find.

-- 
Matthew Phillips
Durham

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web