segmentaion fault with array[4096]

segmentaion fault with array[4096]

[Studencki Pawel]

hello,

because I want to do some tests with fusion/RTAI on my mpc852,
I had to downgrade my system to kernel 2.6.10
And I get a strange problem: if I start application with char array size
4096 (or even smaller 2600) I get "segmentation fault".
Could someone gives me a hint? Is this kernel configuration problem?
Where can I start looking for a reason?

thanks
Pawel

Re: segmentaion fault with array[4096]

[Marcelo Tosatti]

Hi!
On Thu, Aug 18, 2005 at 11:45:04AM +0200, Studencki Pawel wrote:
> hello,
> 
> because I want to do some tests with fusion/RTAI on my mpc852,
> I had to downgrade my system to kernel 2.6.10

Downgrade from what? 

> And I get a strange problem: if I start application with char array size
> 4096 (or even smaller 2600) I get "segmentation fault".
>
> Could someone gives me a hint? Is this kernel configuration problem?
> Where can I start looking for a reason?

Have you tried to debug the application with gdb to spot more precisely 
what is it doing that makes it receive a segfault? 

Most likely its doing an invalid memory access.

RE: segmentaion fault with array[4096]

[Studencki Pawel]

hello,

it is very strange, I found that SIGSEGV is generated in function
do_page_fault() in arch/ppc/mm/fault.c

------------------------------------------------------------------
int do_page_fault(struct pt_regs *regs, unsigned long address,
                  unsigned long error_code)
{
        struct vm_area_struct * vma;
        struct mm_struct *mm = current->mm;
        siginfo_t info;
        int code = SEGV_MAPERR;
#if defined(CONFIG_4xx) || defined (CONFIG_BOOKE)
        int is_write = error_code & ESR_DST;
#else
        int is_write = 0;

        /*
         * Fortunately the bit assignments in SRR1 for an instruction
         * fault and DSISR for a data fault are mostly the same for the
         * bits we are interested in.  But there are some bits which
         * indicate errors in DSISR but can validly be set in SRR1.
         */
//      printk("fault bad_area is_write is NULL %x\n", regs->dsisr);
        if (TRAP(regs) == 0x400)
                error_code &= 0x48200000;
        else
        {
//              printk("fault bad_area is_write err = %x %x\n", error_code,
TRAP(regs));
                is_write = error_code & 0x02000000;
        }
#endif /* CONFIG_4xx || CONFIG_BOOKE */
---------------------------------------------------------------


It is in DSI Exception, so it goes to "else" and sets is_write to value
error_code & 0x02000000, where error_code is DSISR.
it is better, when is_write != 0, because if it's NULL, a few lines below
there
is an "goto" to bad_area:

        if (!is_write)
        {
               goto bad_area;
        } 


and I get exception.
At exception error_code is 0x4821, but in User Manual MPC866 in chapter
6.1.2.3
in table 6-7, they write that bits 0-14 in DSISR are NULL. I'm confused and
I don't know how should I interpret this. Where does value 0x4821 come
from??? most of the time it is 0x82000000...

best regards
Pawel







> -----Original Message-----
> From: Marcelo Tosatti [mailto:marcelo.tosatti@cyclades.com] 
> Sent: Thursday, August 18, 2005 8:01 PM
> To: Studencki Pawel
> Cc: 'linuxppc-embedded@ozlabs.org'
> Subject: Re: segmentaion fault with array[4096]
> 
> Hi!
> On Thu, Aug 18, 2005 at 11:45:04AM +0200, Studencki Pawel wrote:
> > hello,
> > 
> > because I want to do some tests with fusion/RTAI on my mpc852,
> > I had to downgrade my system to kernel 2.6.10
> 
> Downgrade from what? 
> 
> > And I get a strange problem: if I start application with 
> char array size
> > 4096 (or even smaller 2600) I get "segmentation fault".
> >
> > Could someone gives me a hint? Is this kernel configuration problem?
> > Where can I start looking for a reason?
> 
> Have you tried to debug the application with gdb to spot more 
> precisely 
> what is it doing that makes it receive a segfault? 
> 
> Most likely its doing an invalid memory access.
> 

Re: segmentaion fault with array[4096]'

[Marcelo Tosatti]

On Fri, Aug 19, 2005 at 09:17:07AM +0200, Studencki Pawel wrote:
> hello,
> 
> it is very strange, I found that SIGSEGV is generated in function
> do_page_fault() in arch/ppc/mm/fault.c
> 
> ------------------------------------------------------------------
> int do_page_fault(struct pt_regs *regs, unsigned long address,
>                   unsigned long error_code)
> {
>         struct vm_area_struct * vma;
>         struct mm_struct *mm = current->mm;
>         siginfo_t info;
>         int code = SEGV_MAPERR;
> #if defined(CONFIG_4xx) || defined (CONFIG_BOOKE)
>         int is_write = error_code & ESR_DST;
> #else
>         int is_write = 0;
> 
>         /*
>          * Fortunately the bit assignments in SRR1 for an instruction
>          * fault and DSISR for a data fault are mostly the same for the
>          * bits we are interested in.  But there are some bits which
>          * indicate errors in DSISR but can validly be set in SRR1.
>          */
> //      printk("fault bad_area is_write is NULL %x\n", regs->dsisr);
>         if (TRAP(regs) == 0x400)
>                 error_code &= 0x48200000;
>         else
>         {
> //              printk("fault bad_area is_write err = %x %x\n", error_code,
> TRAP(regs));
>                 is_write = error_code & 0x02000000;
>         }
> #endif /* CONFIG_4xx || CONFIG_BOOKE */
> ---------------------------------------------------------------
> 
> 
> It is in DSI Exception, so it goes to "else" and sets is_write to value
> error_code & 0x02000000, where error_code is DSISR.
> it is better, when is_write != 0, because if it's NULL, a few lines below
> there
> is an "goto" to bad_area:
> 
>         if (!is_write)
>         {
>                goto bad_area;
>         } 
> 
> 
> and I get exception.

Sometimes is_write is set and sometimes it is not? Can you please be more 
precise? 

> At exception error_code is 0x4821, but in User Manual MPC866 in chapter
> 6.1.2.3
> in table 6-7, they write that bits 0-14 in DSISR are NULL. I'm confused and
> I don't know how should I interpret this. 

You're looking at the wrong table, thats alignment exception. You should look
at data tlb error exception.

> Where does value 0x4821 come
> from??? most of the time it is 0x82000000...

It probably comes from

	if (TRAP(regs) == 0x400)
                error_code &= 0x48200000;

No?

I think you're just doing something wrong in your app.

Check what instruction resides where the invalid access is done (in your 
application), which vma its trying to access, and you will figure out 
what is going on.