Reply by robe...@yahoo.com October 8, 20072007-10-08
On Oct 8, 4:04 am, karthikbalaguru <karthikbalagur...@gmail.com>
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 : > -------------------------------------------------------------------------=
--=AD----------
> 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 by Stefan Carter October 8, 20072007-10-08
"karthikbalaguru" <karthikbalaguru79@gmail.com> schrieb im Newsbeitrag 
news:1191834268.237871.235950@r29g2000hsg.googlegroups.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
Reply by karthikbalaguru October 8, 20072007-10-08
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