Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!news.cs.indiana.edu!att!pacbell.com!pacbell!osc!chang From: chang@osc.COM (Lai-Chang Woo) Newsgroups: comp.lang.c++ Subject: Wrong delta in virtual table (Glockenspiel C++) Message-ID: <4469@osc.COM> Date: 4 Feb 91 21:26:49 GMT Reply-To: chang@osc.UUCP (Lai-Chang Woo) Organization: Versant Object Technology, Menlo Park, CA Lines: 68 Hello all I am having a nightmarish time with Glockenspiel C++ on DEC/Ultrix 4.0 and just wonder if anyone out there has some hints/suggestions/sympathies to offer. Here's the problem: A simple program fails with segmentation fault. I run it under dbx, examine argument values and find one of the methods "compare" is passed a wrong "this" pointer. I go up one frame and discover the apparent cause of it: the delta value used to compute "this" for this particular virtual function is wrong. I then changed the delta value, and bingo! Case verified. Now the headache: is the Glockenspiel translator to be blamed, or am I doing something to cause this wrong computation? I have a class hierachy which goes like this: class A { // definitions } class B : virtual public A { // some definitions preceeding // first definition of compare method virtual int compare(const B&) const = 0; } class Person : virtual public B { // some definitions preceeding // overriding definition of compare virtual int compare(const B&) const; } class Employee : public Person { // some method definitions // no definition for compare here } The translated C code has virtual tables like these: struct __mptr __vtbl__6B__8Employee[] = {0,0,0, -20,0,(__vptp)methA__8EmployeeCFv, -20,0,(__vptp)methB__8EmployeeCFv, 0,0,(__vptp)methC__6BCFv, -4,0,(__vptp)compare__6PersonCFRC6B, <-- offensive line, works when -4 is ... changed to -20 !! 0,0,0); struct __mptr __vtbl__6B__6Person[] = {0,0,0, -16,0,(__vptp)methA__6PersonCFv, -16,0,(__vptp)methB__6PersonCFv, 0,0,(__vptp)methC__6BCFv, -16,0,(__vptp)compare__6PersonCFRC6B, ... 0,0,0); I am rather new to C++ and don't fully understand the intricacies of the virtual tables, but it appears the translator has either omitted to add -16 to -4, or done an extra subtraction of -16 from -20. Either way, the value calculated by the translator is always the difference; I have verified this point by altering the class definitions such that a whole different set of offsets are computed. Has anybody come across this before? Email replies to "chang%osc.osc.com@ uunet.uu.net" would be appreciated. Thanks in advance.