Tlb Load Exception! - VxWorks

This is a discussion on Tlb Load Exception! - VxWorks ; Gurus, We are using Tornado212 MIPS, vxWorks 5.4.2. The TLB Load exception is happening while accessing NULL pointer ie *(0x0) or strcmp (0,""). But the Tornado221 PPC doesn't have this problem; it is simply returning zero. Though the NULL pointer ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Tlb Load Exception!

  1. Tlb Load Exception!

    Gurus,

    We are using Tornado212 MIPS, vxWorks 5.4.2. The TLB Load
    exception is happening while accessing NULL pointer ie *(0x0) or
    strcmp (0,""). But the Tornado221 PPC doesn't have this problem; it is
    simply returning zero.

    Though the NULL pointer access is invalid; I want to stop the
    Exception and reboot because of that exception.

    Is there any way to fix / handle this in MIPS?

    Thanks & Regards,
    Ramsenthil.

  2. Re: Tlb Load Exception!

    On Sep 24, 12:50 am, RamSen wrote:
    > Gurus,
    >
    > We are using Tornado212 MIPS, vxWorks 5.4.2. The TLB Load
    > exception is happening while accessing NULL pointer ie *(0x0) or
    > strcmp (0,""). But the Tornado221 PPC doesn't have this problem; it is
    > simply returning zero.
    >
    > Though the NULL pointer access is invalid; I want to stop the
    > Exception and reboot because of that exception.
    >
    > Is there any way to fix / handle this in MIPS?
    >
    > Thanks & Regards,
    > Ramsenthil.



    It's my understanding that page 0 is never mapped on the MIPS
    architecture and doing an access there always causes a trap. I think
    on PPC, the exception vector table lives in page 0, so it is mapped.
    However this does not mean that a NULL pointer dereference is not a
    bug on PPC: it just means that instead of an explicit trap, you get
    silent data corruption. The MIPS case is actually preferable since it
    exposes the problem immediately.

    In any case, the correct thing to do is _not_ to ignore the trap.
    There is no legitimate reason to have such invalid pointer use in your
    code: it is a sign of a bug, and you need to fix it instead of
    sweeping it under the rug. The trap generated on MIPS is actually
    useful for debugging exactly this sort of problem (the exception info
    should include the program counter value of the instruction that
    triggered the trap).

    -Bill

  3. Re: Tlb Load Exception!

    On Sep 24, 10:06*pm, noiset...@gmail.com wrote:
    > On Sep 24, 12:50 am, RamSen wrote:
    >
    > > Gurus,

    >
    > > * * * * *We are using Tornado212 MIPS, vxWorks 5.4.2. The TLBLoad
    > > exception is happening while accessing NULL pointer ie *(0x0) or
    > > strcmp (0,""). But the Tornado221 PPC doesn't have this problem; it is
    > > simply returning zero.

    >
    > > * * * * *Though the NULL pointer access is invalid; I want tostop the
    > > Exception and reboot because of that exception.

    >
    > > * * * * *Is there any way to fix / handle this in MIPS?

    >
    > > Thanks & Regards,
    > > Ramsenthil.

    >
    > It's my understanding that page 0 is never mapped on the MIPS
    > architecture and doing an access there always causes a trap. I think
    > on PPC, the exception vector table lives in page 0, so it is mapped.
    > However this does not mean that a NULL pointer dereference is not a
    > bug on PPC: it just means that instead of an explicit trap, you get
    > silent data corruption. The MIPS case is actually preferable since it
    > exposes the problem immediately.
    >
    > In any case, the correct thing to do is _not_ to ignore the trap.
    > There is no legitimate reason to have such invalid pointer use in your
    > code: it is a sign of a bug, and you need to fix it instead of
    > sweeping it under the rug. The trap generated on MIPS is actually
    > useful for debugging exactly this sort of problem (the exception info
    > should include the program counter value of the instruction that
    > triggered the trap).
    >
    > -Bill



    Thanks Bill! I do understand, NULL pointer dereference is illegal. We
    are doing porting from PPC to MIPS. We are facing lot of exceptions
    due to poor coding. We almost corrected everthing. For saferside, the
    client wants to have the support for NULL access...

    Is there any way to map Page 0 in MIPS? Or atleast some other dummy
    mapping for address 0x0?

    Where could we find these mapping in VxWorks 5.4.2?

    Thanks & Regards,
    Ramsenthil.

  4. Re: Tlb Load Exception!

    On Sep 25, 12:57 am, RamSen wrote:
    > On Sep 24, 10:06 pm, noiset...@gmail.com wrote:
    >
    >
    >
    > > On Sep 24, 12:50 am, RamSen wrote:

    >
    > > > Gurus,

    >
    > > > We are using Tornado212 MIPS, vxWorks 5.4.2. The TLB Load
    > > > exception is happening while accessing NULL pointer ie *(0x0) or
    > > > strcmp (0,""). But the Tornado221 PPC doesn't have this problem; it is
    > > > simply returning zero.

    >
    > > > Though the NULL pointer access is invalid; I want to stop the
    > > > Exception and reboot because of that exception.

    >
    > > > Is there any way to fix / handle this in MIPS?

    >
    > > > Thanks & Regards,
    > > > Ramsenthil.

    >
    > > It's my understanding that page 0 is never mapped on the MIPS
    > > architecture and doing an access there always causes a trap. I think
    > > on PPC, the exception vector table lives in page 0, so it is mapped.
    > > However this does not mean that a NULL pointer dereference is not a
    > > bug on PPC: it just means that instead of an explicit trap, you get
    > > silent data corruption. The MIPS case is actually preferable since it
    > > exposes the problem immediately.

    >
    > > In any case, the correct thing to do is _not_ to ignore the trap.
    > > There is no legitimate reason to have such invalid pointer use in your
    > > code: it is a sign of a bug, and you need to fix it instead of
    > > sweeping it under the rug. The trap generated on MIPS is actually
    > > useful for debugging exactly this sort of problem (the exception info
    > > should include the program counter value of the instruction that
    > > triggered the trap).

    >
    > > -Bill

    >
    > Thanks Bill! I do understand, NULL pointer dereference is illegal. We
    > are doing porting from PPC to MIPS. We are facing lot of exceptions
    > due to poor coding. We almost corrected everthing. For saferside, the
    > client wants to have the support for NULL access...


    Tell your client he's wrong! This is not the "saferside!" Ignoring
    these traps is EXTREMELY UNSAFE! You must fix the code! You should
    consider it a miracle that the PPC-based device running this code did
    not crash left and right!

    People use VxWorks in many applications where safety is critical, such
    as industrial automation and medical diagnosis/therapy machines. Bugs
    of this nature (wild pointers) can cause all kinds of unpredictable
    failures, and with safety critical systems an unpredictable failure
    could lead to injury or death. I sincerely hope that your client's
    device is not of this nature, because if it is they're advocating
    putting their customers at a terrible risk.

    "Supporting NULL access" is not a feature. It does not immunize your
    code against crashes. It just makes you vulnerable to more
    unpredicable crashes in the future. The fact that you got away with it
    on PPC is truly unfortunate, particularly since it seems to have given
    you (and the client) the idea that it was okay to deploy buggy code.
    Here, the MIPS processor is being kind enough to show you exactly
    where the bugs are: pay attention to what it's telling you and fix the
    problems instead of ignoring them. Even if your target device is not
    safety-critical, deliberately trying to make it ok to have NULL
    pointer dereferences in your code is very poor practice.

    You are also going to find that VxWorks/MIPS is not the only case
    where the NULL pointer dereferences immediately produce a fatal
    runtime error. With VxWorks 6.x using RTPs (i.e. protection domains),
    you would have also gotten a trap no matter which architecture you
    used. With UNIX, you would have gotten a segmentation fault.

    > Is there any way to map Page 0 in MIPS? Or atleast some other dummy
    > mapping for address 0x0?
    >
    > Where could we find these mapping in VxWorks 5.4.2?


    Even if I knew, I would not tell you. (Note that there is a documented
    way of creating custom exception handlers, but I'm not going to go
    into it here since I think it would only be an even bigger bullet with
    which to shoot yourself in the foot.) What you really must do is:

    - Fix all the NULL pointer bugs exposed by the MIPS arch
    - Institute a rigorous testing process
    - Do a full formal review of the code

    I know you think this may be a lot of work. I know it may interfere
    with your deadlines. I know your client may not be thrilled at the
    prospect of the extra costs and scheduling delays this may incurr. But
    please, I implore you: fix the damn code.

    -Bill
    > Thanks & Regards,
    > Ramsenthil.



  5. Re: Tlb Load Exception!

    On Sep 25, 11:12*pm, noiset...@gmail.com wrote:
    > On Sep 25, 12:57 am, RamSen wrote:
    >
    >
    >
    >
    >
    > > On Sep 24, 10:06 pm, noiset...@gmail.com wrote:

    >
    > > > On Sep 24, 12:50 am, RamSen wrote:

    >
    > > > > Gurus,

    >
    > > > > * * * * *We are using Tornado212 MIPS, vxWorks 5.4.2. TheTLB Load
    > > > > exception is happening while accessing NULL pointer ie *(0x0) or
    > > > > strcmp (0,""). But the Tornado221 PPC doesn't have this problem; itis
    > > > > simply returning zero.

    >
    > > > > * * * * *Though the NULL pointer access is invalid; I want to stop the
    > > > > Exception and reboot because of that exception.

    >
    > > > > * * * * *Is there any way to fix / handle this in MIPS?

    >
    > > > > Thanks & Regards,
    > > > > Ramsenthil.

    >
    > > > It's my understanding that page 0 is never mapped on the MIPS
    > > > architecture and doing an access there always causes a trap. I think
    > > > on PPC, the exception vector table lives in page 0, so it is mapped.
    > > > However this does not mean that a NULL pointer dereference is not a
    > > > bug on PPC: it just means that instead of an explicit trap, you get
    > > > silent data corruption. The MIPS case is actually preferable since it
    > > > exposes the problem immediately.

    >
    > > > In any case, the correct thing to do is _not_ to ignore the trap.
    > > > There is no legitimate reason to have such invalid pointer use in your
    > > > code: it is a sign of a bug, and you need to fix it instead of
    > > > sweeping it under the rug. The trap generated on MIPS is actually
    > > > useful for debugging exactly this sort of problem (the exception info
    > > > should include the program counter value of the instruction that
    > > > triggered the trap).

    >
    > > > -Bill

    >
    > > Thanks Bill! I do understand, NULL pointer dereference is illegal. We
    > > are doing porting from PPC to MIPS. We are facing lot of exceptions
    > > due to poor coding. We almost corrected everthing. For saferside, the
    > > client wants to have the support for NULL access...

    >
    > Tell your client he's wrong! This is not the "saferside!" Ignoring
    > these traps is EXTREMELY UNSAFE! You must fix the code! You should
    > consider it a miracle that the PPC-based device running this code did
    > not crash left and right!
    >
    > People use VxWorks in many applications where safety is critical, such
    > as industrial automation and medical diagnosis/therapy machines. Bugs
    > of this nature (wild pointers) can cause all kinds of unpredictable
    > failures, and with safety critical systems an unpredictable failure
    > could lead to injury or death. I sincerely hope that your client's
    > device is not of this nature, because if it is they're advocating
    > putting their customers at a terrible risk.
    >
    > "Supporting NULL access" is not a feature. It does not immunize your
    > code against crashes. It just makes you vulnerable to more
    > unpredicable crashes in the future. The fact that you got away with it
    > on PPC is truly unfortunate, particularly since it seems to have given
    > you (and the client) the idea that it was okay to deploy buggy code.
    > Here, the MIPS processor is being kind enough to show you exactly
    > where the bugs are: pay attention to what it's telling you and fix the
    > problems instead of ignoring them. Even if your target device is not
    > safety-critical, deliberately trying to make it ok to have NULL
    > pointer dereferences in your code is very poor practice.
    >
    > You are also going to find that VxWorks/MIPS is not the only case
    > where the NULL pointer dereferences immediately produce a fatal
    > runtime error. With VxWorks 6.x using RTPs (i.e. protection domains),
    > you would have also gotten a trap no matter which architecture you
    > used. With UNIX, you would have gotten a segmentation fault.
    >
    > > Is there any way to map Page 0 in MIPS? Or atleast some other dummy
    > > mapping for address 0x0?

    >
    > > Where could we find these mapping in VxWorks 5.4.2?

    >
    > Even if I knew, I would not tell you. (Note that there is a documented
    > way of creating custom exception handlers, but I'm not going to go
    > into it here since I think it would only be an even bigger bullet with
    > which to shoot yourself in the foot.) What you really must do is:
    >
    > - Fix all the NULL pointer bugs exposed by the MIPS arch
    > - Institute a rigorous testing process
    > - Do a full formal review of the code
    >
    > I know you think this may be a lot of work. I know it may interfere
    > with your deadlines. I know your client may not be thrilled at the
    > prospect of the extra costs and scheduling delays this may incurr. But
    > please, I implore you: fix the damn code.
    >
    > -Bill
    >
    >
    >
    > > Thanks & Regards,
    > > Ramsenthil.- Hide quoted text -

    >
    > - Show quoted text -- Hide quoted text -
    >
    > - Show quoted text -


    Thanks a lot for your advices. I will try to follow all your
    suggestions.

+ Reply to Thread