[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] microblaze: Use of sigaction() leads to crash on exit
Hi John,
On Thu, 2009-11-12 at 10:14 +1000, John Williams wrote:
>
> On Wed, Nov 11, 2009 at 2:01 AM, Steven J. Magnani
> <steve@xxxxxxxxxxxxxxx> wrote:
>
> > I've finished porting my noMMU kernel to 2.6.31 and believe I've adapted
> > my uClibc to the ABI changes (typedefs, system call changes,
> > SA_RESTORER, etc.) in that release. Most things run fine, which is a
> > great improvement over my initial port attempt that crashed and burned.
> >
> > What I see now (and have ever since 2.6.30) is that quitting the 'top'
> > program (the procps one, not the busybox one) crashes the entire system.
> > If I comment out the calls to sigaction() in top.c, I can quit the
> > program just fine (as long as it's running at the serial console) and
> > the system stays up. The system still crashes if I try to quit a 'top'
> > running in a telnet session, which I think is a separate issue.
> >
> > Has anyone else running 2.6.3x encountered similar problems, or can
> > confirm this behavior?
>
> I remember when I did some work to bring uClibc up to 0.9.30.1, that
> MicroBlaze sighandling had bit-rotted somewhat in the uclibc.org
> trees, because they'd changed the internal structure and made fairly
> mechanical and incorrect attempts to bring microblaze forward.
I'm still working with 0.9.27, if that's an issue. I have the 0.9.30
tarball, I'll look it over.
>
> I'll dig out some patches that may help.
Thanks!!
>
> > I noticed that 2.6.31 made some changes to Microblaze signal handling
> > that bring it more in line with the generic kernel code. Were there also
> > problems that were being addressed by those changes?
>
> I think more likely is the change to sighandling internals in uClibc.
> We didn't have to do anything magical to glibc for example, to get the
> new sighandling in place for the MMU variant.
It seems to be a problem in uClibc's __libc_sigaction(). If my 'top'
program goes in there at all, the system crashes when 'top' exits.
That's true even if I change the function so it returns immediately. I
suspect scribbling on the program stack, but can't find the culprit.
Could it be a gcc "weak_alias" thing?
-- Steve
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/