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