Dynamic function call

[David Korn]

>-----Original Message-----
>From: Daniel.Andersson@combitechsystems.com
>Sent: 14 June 2001 16:04

>Well, i really dont want a list but an array that holds pointers to the
>functions that a want to call. I have declared AttachedObjects as "CCommon
>*AttachedObjects[NBR_OF_OBJS]".

>> See, that will be the only object that gets messages for USERS: if there
>> was already one registered, it will be overwritten in the array.
>
>I see what you mean but that is not a problem at this time since only one
>object wants the message.

  Ah, OK, I didn't quite understand.  Anyway, whether just one object
gets the message or lots do, the call should still work the same anyway.

>I do have declared the base class (CCommon) function to be virtual:
>"virtual void EventHandler(MessageRaw_t *pMsg);" since i always want to
>override it with my functions in the derived classes.
>
>Can it be something with my environment that doesn't handle this dynamic
>calls to functions?

  It shouldn't be a problem.  A virtual function call is basically the
same as calling a function via a pointer, with the slight complication
that the pointer has to be looked up in an array, and the array has to
be looked up from a pointer in the actual object itself.

>When i run the line 
>   "AttachedObjects[msgRaw->Receiver]->EventHandler(msgRaw)
>then i get a "sig trap" from GDB. I assume that this means that i have made
>a reference to a memory that isn't available and that the reason for this
>is a pointer that has a strange value. However, when i take a look at all
>the attached objects (CAR, NODEMANAGER, USERS) in the AttachedObjects[]
>then they all reside within RAM so i think that they have correct memory
>values in their registered "this"-pointers. 

  Ah, well in this case the pointer in question could be your CPU's 
program counter.  What has probably happened here is that there was a stray
pointer or array bounds overflow earlier in the code; this has overwritten
some memory, and has trashed either a) the pointer in the object that points
to the array of virtual function pointers, or b) the actual array of virtual
function pointers (called the _vtbl) itself.  You could start trying to find
out what's gone wrong by running just up to the line you mentioned above
in GDB, then look at the object pointed to by the 'this' pointer , find the
pointer in that object to its vtbl (should be the first 4 bytes of the
object), finally look through that table and see if it contains the addrs
of valid functions or not.

  I'll explain the vtbl in more detail tomorrow if this doesn't give you
enough info to find the bug, but I have to leave work and go home now. 
(Hooray!)


         DaveK
-- 
we are not seats or eyeballs or end users or consumers.
we are human beings - and our reach exceeds your grasp.
                    deal with it.                      - cluetrain.org 


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com