Re: [gccsdk] stderr 2 file advantage

In message <20121220224639.08723243FB@orac.inputplus.co.uk>
Ralph Corderoy <ralph@inputplus.co.uk> wrote:

> John wrote:
> > > Very bizar, looks like a real bug somewhere but someone needs to dig
> > > into this as I don't think we can just guess it based on above facts
> > > only.
>
> Perhaps there's something up with stderr, file descriptor 2, and that
> causes the first signal the handling of which wobbles because it would
> like to use stderr?
>
> Is there something on RISC OS like strace(1) now? On Linux, one can see
> tar doing things like GET_FD on FD 2 early on, with, for example, an
> opening of /dev/null if it's a bad file descriptor.
>
> tar -xvf foo.tar 2>&-
>
> Cheers, Ralph.

The tough thing about this instability, is that it is almost a moving
target.
Since the above occurrence, I haven't been automatically getting the
SIGSEV error, and when I do get it, the stderr direction now doesn't
help at all.
So stderr is looking like a red herring now.
Other command modifying can get it to work.
The --format=pax addition seems to always make it work but
I am beginning to see that it is to do with changing the 'weight' of
the command rather than it being needed.
Using the form -vx --file=foo.tar seems to be a fix also, but time will
tell, as I think that varying command content can change the behaviour.

To add to the changes brought about by tar command changes, I have
also found that the RISC OS path to the tar binary can affect it.

I can get this to error (foo.tar is in CSD in RAM:)
ADFS::HardDisc4.$.!TarCtrl.Files.Bin.tar vxf foo.tar
but moving the tar binary to the same directory and all is OK.
tar vxf foo.tar

The few times I have tried the older tar package with tar 1.22
it has coped with the same situation that stops my later 4x port
of 1.26 also, so I'm assuming this command instability is from
either our modern cross compiler or the newer tar 1.26.

The fact that the variation of the RISC OS path to the binary
can alter the behaviour might suggest that the instability is
brought about at an early SharedLibs stage -perhaps.
Or maybe CSD related, I think I /did/ update my crosscompiler
after noticing some recent changes in that area though.

Thanks, Ron M.






_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK