[sdcc-devel] 16 bits short: prologue : Access violation

[Jerome B. <jer...@fr...>]

   A bit more about access violation ...

   ++++++++++++++++++++++++++++++
  The problem starts in SDCC.y
(When declaring struct and tag in the target source)

opt_stag
   : stag
   |  {  /* synthesize a name add to structtable */
---> Here newStruct return structdef *
         $$ = newStruct(genSymName(NestLevel)) ;
         $$->level = NestLevel ;
---> Here we call addsym with $$ (Second parameter) that point on a strucdef
data
         addSym (StructTab, $$, $$->tag,$$->level,currBlockno)
      }
   ;

stag
   :  identifier  {  /* add name to structure table */
                     $$ = findSymWithBlock (StructTab,$1,currBlockno);
                     if (! $$ ) {
                        $$ = newStruct($1->name) ; --> Same as above
                        $$->level = NestLevel ;
                        addSym (StructTab, $$,
$$->tag,$$->level,currBlockno) ;--> Same as above
                     }
                  }
   ;


   ++++++++++++++++++++++++++++++++++
   Next in SDCCSymt.c function addSym

   void addSym (bucket ** stab,
   void *sym, <--- ------------------------sym is not necessary a symbol
   char *sname,int level,int block)
   {
   ....

   /* Make sure sym is a symbol and not a structdef */
---> Fix disabled
/*
----> This test is needed to avoid erratic access violation when sym isn't
really of type symbol
 if (StructTab!=stab)
*/
{
   /* make sure the type is complete and sane */
   checkTypeSanity(((symbol *)sym)->etype, ((symbol *)sym)->name);

----> Here we try to acces ((symbol *)sym)->etype but sym doesn' point to a
symbol but to a structdef data. Then, when we try to access etype we point
 somewhere after the end of current structdef allocated data; noticed that
sizeof(strucdef) is lower than sizeof(symbol) then etype is located after
the end of the strucdef.
If we are lucky etype of type struct sym_link * will be NULL and nothing
will be bad. But depends on what is allocated after the current structdef
data pointed by sym parameter; then etype can be an invalid pointer and this
leads to erratic access violation.
   }

   ...

 Nothing wrong in calloc (I don't use cygwin) and I sometimes fall into this
problem.

 Hope this help Johan to understand what is going wrong.
Sorry for my english, it doesn't help me to clarify this point.

 Jérôme

   -------------------------------------------------------------------------
   FROM: Johan Knol
   DATE: 06/13/2001 00:48:11
   SUBJECT: RE: [sdcc-devel] 16 bits short: prologue : Access violation

   That's all I could figure out. Any questions?

   I disabled Jérôme's fix to try to reproduce it, but I couldn't. This
   obviously wasn't meant to be committed.
   The only thing I can think of is a flaw in the calloc of cygwin.

   Please try again.

   Johan