bcopy - VxWorks

This is a discussion on bcopy - VxWorks ; Hi, I find that the stackpointer is pointing to 'bcopy' at the time of crash of my VxWorks application. This was found by analysing the log file and the Vxworks MAP files. On stack traceback, i find that 'bcopy' is ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: bcopy

  1. bcopy

    Hi,

    I find that the stackpointer is pointing to 'bcopy' at the time of
    crash of my VxWorks application.
    This was found by analysing the log file and the Vxworks MAP files.

    On stack traceback, i find that 'bcopy' is being called by another
    routine (namely 'A').

    I do not find 'bcopy' being called from that routine(namely 'A').
    But, i find memcpy inside that routine (namely 'A').

    Questions specific to the crash problem :
    ---------------------------------------------------------------
    Does 'memcpy' use 'bcopy' internally in VxWorks ?
    Is 'bcopy' being called/used by some other internal API of VxWorks ?
    How to know about this ?
    Any other method to trace the function from which the bcopy is being
    called ?

    Other Main Questions In general to tackle the crash problem :
    -------------------------------------------------------------------------------------
    Why does my application crash at 'bcopy' ? Any possible reasons for
    this ? Anyone has faced this ?

    Thx in advans,
    Karthik Balaguru


  2. Re: bcopy


    "karthikbalaguru" schrieb im Newsbeitrag
    news:1191834268.237871.235950@r29g2000hsg.googlegr oups.com...
    > Why does my application crash at 'bcopy' ? Any possible reasons for
    > this ?


    What about the destination address? If a binary copy (memcopy) crashes the
    software, it usually did so by overwriting something of importance (like
    stack, interrupt vectors, program code where possible, or other niceties).
    Maybe the destination parameter or the length is not what it should be
    (writing just one byte too much resp. too far frequently yields interesting
    effects).

    So, the culprits are usually: wrong transfer length or invalid destination
    address (in that order, and sometimes both).

    Hope it helps,

    Stefan



  3. Re: bcopy

    On Oct 8, 4:04 am, karthikbalaguru
    wrote:
    > Hi,
    >
    > I find that the stackpointer is pointing to 'bcopy' at the time of
    > crash of my VxWorks application.
    > This was found by analysing the log file and the Vxworks MAP files.
    >
    > On stack traceback, i find that 'bcopy' is being called by another
    > routine (namely 'A').
    >
    > I do not find 'bcopy' being called from that routine(namely 'A').
    > But, i find memcpy inside that routine (namely 'A').
    >
    > Questions specific to the crash problem :
    > ---------------------------------------------------------------
    > Does 'memcpy' use 'bcopy' internally in VxWorks ?
    > Is 'bcopy' being called/used by some other internal API of VxWorks ?
    > How to know about this ?
    > Any other method to trace the function from which the bcopy is being
    > called ?
    >
    > Other Main Questions In general to tackle the crash problem :
    > ---------------------------------------------------------------------------*----------
    > Why does my application crash at 'bcopy' ? Any possible reasons for
    > this ? Anyone has faced this ?



    The semi-standard bcopy() performs the identical function as memcpy on
    most platforms (it'll be a bit different on platforms where size_t
    isn't an int). And on more than one system I've seen, one of the
    functions is just an alias for the other in the library (so there's no
    physically separate version). That's actually a fairly common
    implementation technique - for example, the long double functions are
    often just aliases for the double functions since on most platforms
    there's no difference in the underlying type.

    OTOH, memcpy() could certainly be implemented as a wrapper around
    bcopy, or, on some platforms, just a jump to the bcopy routine. But
    that's not really an issue - if you're in bcopy, and the stack trace
    shows that you're coming from a routine that called memcpy, I'd just
    go with the assumption that the two functions are somehow intertwined
    in VxWorks.

    As to why it's crashing, it's because you've tried to access a region
    of memory in a way you aren't allowed too. So one or more of the
    three parameters are causing you to access memory you've not properly
    allocated. IOW, you have a bad pointer, or a length that's too large.


+ Reply to Thread