bcopy

"karthikbalaguru" schrieb im Newsbeitrag news: snipped-for-privacy@r29g2000hsg.googlegroups.com...

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

--=AD----------

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.