[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference decwet::visual

Title:Microsoft Visual C++ bug reports and kits
Notice:Register in Topic 2. 5.Last for latest Kit
Moderator:DECWET::THOMASN
Created:Tue May 17 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:521
Total number of notes:2938

449.0. "preprocessing problem v4.2b" by AXPBIZ::bpda02::PHEBERT (Mr. Knobby rides again. and again and again...) Fri Jan 17 1997 10:37

T.RTitleUserPersonal
Name
DateLines
449.1project makefile for sample programAXPBIZ::bpda02::PHEBERTMr. Knobby rides again. and again and again...Fri Jan 17 1997 10:38190
449.2initial pass infoDECWET::BERGMon Jan 27 1997 12:116
Both the Alpha and Intel vc5.0 compilers have this problem, suggesting a change in the 
FE.  I'll look into the differences between the Intel an Alpha beta 4.2 compiler to see if
I can find a reason for the preproccessor problem.  FYI: Neither Phil or Myself have modified the 
preprocessor in any way.

--Mike
449.3DECC::OUELLETTEMon Jan 27 1997 13:0615
Note that back before VC2.0, we grew the size of the macro expansion buffer
in the frontend from something like 2K to something like 32K characters for
Alpha only.  But that does not appear to be the problem here.

                       <<< Note 449.2 by DECWET::BERG >>>
                             -< initial pass info >-

Both the Alpha and Intel vc5.0 compilers have this problem, suggesting a
change in the FE.  I'll look into the differences between the Intel an
Alpha beta 4.2 compiler to see if I can find a reason for the preproccessor
problem.  FYI: Neither Phil or Myself have modified the preprocessor in any
way.

--Mike

449.4DECWET::BERGTue Jan 28 1997 17:436
Roland, it's hard to tell what has been done to this copy of the code.  Could you find
a version that works exactly the way it was reported and put it on \\ntnone\vc$\temp.
Notes may have added things...
And, is this the version that was in the original code or is this the .i file after precompile?

--Mike
449.5DECCXL::OUELLETTEWed Jan 29 1997 09:4916
Mike,

Please contact Paul Hebert for it.  I neither have access to
\\ntnone\vc$\temp, nor any other info about the problem.
I've no idea of how Notes may have added anything.

                       <<< Note 449.4 by DECWET::BERG >>>

Roland, it's hard to tell what has been done to this copy of the code.
Could you find a version that works exactly the way it was reported and put
it on \\ntnone\vc$\temp.  Notes may have added things...  And, is this the
version that was in the original code or is this the .i file after
precompile?

--Mike

449.6new sample code showing bugAXPBIZ::bpda02::PHEBERTMr. Knobby rides again. and again and again...Tue Feb 04 1997 15:1929
Okay, we have a new sample program that reproduces the failure mode we were 
trying to describe earlier.  Just for added clarity, there are two problems 
entwined in this scenario...

The preprocessor expansion, which is different on Intel vs Alpha v4.2 
toolset and appears to choke the compiler is the first.  This is understood 
already and has been reproduced in both the Intel and Alpha v5 compilers.  
The implicit workaround is to avoid the macro-expansion step.

Then there is a problem at run-time, in which an address pointer appears to 
be clobbered leading to an access violation.  
In
   \\knobby\Coolbug\enumtest.zip 

is everything you need to reproduce the run time error.  A fairly detailed 
description of the debug work already done to isolate it is in the initial 
comments in the sample code.  I have reproduced the error here in Palo 
Alto.  It may be interesting to note that on the sample program, the 
release version appears to run alright, but the debug version shows the 
problem.  

The \\knobby\Coolbug share also contains the expanded contents of the zip 
file and built versions of the debug and release targets.  These have 
been built on NTv4.0 systems with VCPP v4.2b.  If you have problems 
accessing or reproducing the result, please give me a call (dtn 543.3659).  
Also feel free to contact the contractor who packaged this problem for us, 
Tim Mooring, at 415.507.8796.  

Thanks
449.7reminder of path name...DECCXL::OUELLETTEWed Feb 05 1997 09:031
xcopy /s/d/e \\knobby.pa.dec.com\Coolbug\enumtest.zip dest-directory\
449.8DECWET::THOMASBug-for-bug compatible with IntelWed Feb 05 1997 15:377
    I've reproduced this here on 4.2b. Interestingly the 5.0 compiler gets
    a bunch of errors compiling this.
    
    It'll be a while before anyone can look further at this - most of us
    will be at a class Thursday and Friday.
    
    	Mike
449.9workaround? and a little more infoAXPBIZ::bpda02::PHEBERTMr. Knobby rides again. and again and again...Wed Feb 05 1997 17:1720
Glad we've gotten even this synchronized.  At this point this bug has our 
development work on the main product stopped.  Programmers are filling in 
the time with side tasks, but most depend on the main product to test the 
outcome in any case.  Tim M. has asked me if the code suggests any ideas 
for a workaround that might get him up and running while a proper fix is 
found.  Perhaps the v5 compilers compile-time errors suggest something in 
this area?

Also, FWIW, Tim has looked very closely at this thing for almost a week 
running now, so a telephone call to him may get lots of useful descriptive 
info to refine the problem statement and hint at the core problem.  As 
the middle-man in this conversation, I believe a brief call between one of 
you, who knows the compiler well, and Tim, who knows the failing behavior 
well, could save alot of time and trouble at both ends.  He has gone so far 
as to study the code at the dissassembly level and compare with his 
expectations from reading the calling standard.  He is able to patch around 
it in the debugger, but there are too many instances of the failing class 
to patch the image fully.  He believes this is a serious bug, perhaps more 
than one.

449.10Workaround available at last...DECWET::BERGFri Feb 07 1997 22:41191
Bingo, got it!

I changed the HT_Image_Format instance to a pointer and watched to see what would happen.
Sure enough, the pointer was mangled between the macro call,

(*act.m_action) (*act.renderer_data(), width, height, format, buffer);

and 

dibsection_create_frame_buffer(...) {...}

The pointer in side the later is 0x00000010, which is really bogus, and
outside, its 0x0012fef0, which is correct.

Which means that the function resolution for (*act.m_action)
is hosing this u
.

The work around is in the following file(read line 63).

--Mike

//  Copyright (c) 1994 - 1996 by Autodesk, Inc.
//  The information contained herein is confidential and proprietary to
//  Autodesk, Inc., and considered a trade secret as defined under civil and
//  criminal statutes.  Autodesk shall pursue its civil and criminal remedies
//  in the event of unauthorized use or misappropriation of its trade
//  secrets.  Use of this information by anyone other than authorized
//  employees of Autodesk, Inc. is granted only under a written
//  non-disclosure agreement, expressly prescribing the scope and manner of
//  such use.
//
//Begin remarks DecAlpha Port: tgm 2/4/97
//This program is a self-contained reduction of an error context
//related to loss of reference (this pointer) to a temporary object
//of class HT_ImageFormat. (AutoDesk Whip/Heidi Display Driver). The
//temporary object is created on the stack frame in main() in the call
//to create_frame_buffer() (register a3). In create_frame_buffer(),
//USE_ACTION loads a function pointer to dibsection_create_frame_buffer().
//In marshalling the parameters for this call, the HT_Image_Format
//reference, again in register a3, is overwritten.
//
//VC4.2b, Intel(blend) and Alpha(blend)
//Runs on Intel(Pentium Pro 200), Access Violation on Alpha(321064)
//
#define alter
#define null 0
#define HEIDI_API __declspec( dllexport )
#define HEIDI_CALL __cdecl

typedef unsigned char   HT_Boolean;
typedef void (HEIDI_CALL * HT_Action_Routine)(...);

class HT_Image_Format {
    public:
        enum Enum {
            bitonal,
            index8,
            rgb32,
            depth16,
            depth32,
            any,
            device_specific,
            invalid = -1
        };
    protected:
 Enum m_value;
 public:
 HT_Image_Format() : m_value ((Enum) 0) {}
 HT_Image_Format(HT_Image_Format const & in) : m_value (in.m_value) {}
 HT_Image_Format(HT_Image_Format::Enum in) : m_value (in) {}
 operator int() const {return (int) m_value;}
 HT_Image_Format const & operator= (HT_Image_Format const & in)  {m_value = in.m
_value; return *this;}
 HT_Image_Format const & operator= (HT_Image_Format::Enum in)  {m_value = in; re
turn *this;}
 HT_Boolean operator== (HT_Image_Format const & in) const {return m_value == in.
m_value;}
 HT_Boolean operator== (HT_Image_Format::Enum in) const {return m_value == in;}
 HT_Boolean operator!= (HT_Image_Format const & in) const {return m_value != in.
m_value;}
 HT_Boolean operator!= (HT_Image_Format::Enum in) const {return m_value != in;}
};

void dibsection_create_frame_buffer( int rc, int width, int height,
                                     HT_Image_Format format,
                                     int *buffer )
{
// NOTE: rc is an instance of HT_Renderer_Data disguised as an int.
if( format != HT_Image_Format::index8 )  //tgm Access Violation occurs here
  {
  return;
  }
return;
}

class  HT_Int_XY
{
public:
  int             x, y;
  HT_Int_XY () {}
  HT_Int_XY (int px, int py) : x (px), y (py) {}
};

class HT_Action_Entry {
  friend class HT_Renderer_Data;
private:
  HT_Renderer_Data const *        m_renderer_data;
  HT_Action_Routine               m_action;
  enum State {
             Unset,
             Set,
             Inherited
             } m_state;
public:
  void set (HT_Renderer_Data const * r, HT_Action_Routine a) alter {
   if (a != null) {
                m_renderer_data = r;
                m_action = a;
                m_state = Set;
            }
            else
                m_state = Unset;
        }

  HT_Renderer_Data const * renderer_data (void) const {return m_renderer_data;}
};

class HT_Renderer_Options
{
friend class HT_Renderer_Data;
protected:
    int left, right, m_options;

public:
    HT_Renderer_Options() { m_options = 10; left = 20; right = 30; }
    HEIDI_API HT_Int_XY window_size (void) const;
};

HT_Int_XY HT_Renderer_Options::window_size (void) const {
  return HT_Int_XY (left, right);
}

#define USE_ACTION(i,v) register  HT_Action_Entry const &  v = m_draw[i]
#define SET_ACTION(i,a) set_action (i, (HT_Action_Routine)(a))

class HT_Renderer_Data {
friend class HT_Renderer_Options;
public:
enum {
     Draw1,
     Draw2,
     Draw3,
     Create_Frame_Buffer,
     Total_Routines
     };
protected:
  HT_Action_Entry    m_draw[Total_Routines];
  HT_Renderer_Options m_renderer_current_options;
public:
HT_Renderer_Options const & current_renderer_options () const {return m_renderer
_current_options;}
void create_frame_buffer (int width, int height,
                         HT_Image_Format format,
                         int *buffer)
  {
  USE_ACTION (Create_Frame_Buffer, act);
  dibsection_create_frame_buffer ((int) act.renderer_data(), width, height, form
at, buffer);
  //(*act.m_action) (*act.renderer_data(), width, height, format, buffer);
  }
void set_action (int index, HT_Action_Routine a) alter {
  m_draw[index].set (this, a);
  }
HT_Renderer_Data();
};

HT_Renderer_Data::HT_Renderer_Data()
{
        SET_ACTION(Create_Frame_Buffer, dibsection_create_frame_buffer);
}

int main()
{
int buffer =0xefef;
HT_Renderer_Data t;

t.create_frame_buffer (t.current_renderer_options().window_size().x,
                       t.current_renderer_options().window_size().y,
                       HT_Image_Format::index8, &buffer);
return( 0 );
}
449.11workaround at last...DECWET::BERGFri Feb 07 1997 22:425
Paul, you will also find the file, main.cpp at

\\knobby.pa.dec.com\Coolbug

--Mike