RE: segmentaion fault with array[4096]

2 messages, 2 authors, 2005-08-21 · open the first message on its own page

RE: segmentaion fault with array[4096]

From: Studencki Pawel <hidden>
Date: 2005-08-19 07:26:32

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:
quoted
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? 
quoted
And I get a strange problem: if I start application with 
char array size
quoted
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]'

From: Marcelo Tosatti <hidden>
Date: 2005-08-21 19:37:19

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help