0

Here a snippet of generated .c code from .Lex.
And the Coredump is coming at the very first Iteration 

while (1)   /* loops until end-of-file is reached */{
   yy_cp = yy_c_buf_p;

    /* Support of yytext. */
    *yy_cp = yy_hold_char;   // receiving coredump here

    /* yy_bp points to the position in yy_ch_buf of the start of
     * the current run.*/

     yy_bp = yy_cp;
     yy_current_state = yy_start;}

Here you can find code

mik
  • 73
  • 8
  • Please let me know If you people need some more inputs – mik Jan 17 '15 at 12:04
  • The obvious question is, why do you think yy_c_buf_p is valid? – Ira Baxter Jan 17 '15 at 15:10
  • Presumably you've managed to avoid initializing the flex buffer. Please show your actual code, not the generated code. – rici Jan 17 '15 at 17:26
  • @rici : Please find the code here [link]https://gist.github.com/mohakhan/bc4dff99ce1c5d742ff0#file-lex-lex – mik Jan 17 '15 at 18:38
  • @mik: Lots of questionable stuff there, but nothing which should lead to a segfault. Why are you defining `YYLMAX`? That has not effect unless you specify `%array`, which as far as I can see you do not do and which is rarely a good idea. Are you invoking flex with `-l`? And with what other options? – rici Jan 17 '15 at 19:53
  • @rici : frankly speaking I don't have to much idea about Lex and Yaac. I am working on a legacy code written in 1990. For your information I am compiling lex without any option ( lex fileName.l) – mik Jan 18 '15 at 02:24
  • @mik: ok, the generated code snippet looks like an old version of flex, but it's possible that invoking it as `lex` adds the lex-compatibility flag. Anyway, I don't see anything which would cause `yy_c_buf_p` to be wrong in your lex file, but it might be elsewhere. (And, of course, a memory corruption bug could be almost anywhere.) – rici Jan 18 '15 at 02:47
  • @IraBaxter : Yes I am comparing this buff values from other. And for my code it is '0' (NULL). How to identify? and what chages required correct initialization of yy_c_buf_p ? – mik Jan 18 '15 at 03:35
  • @IraBaxter: In very First Iteration of while (1): For other code : yy_hold_char = ^@ yy_c_buf_p = 312015256 But For this problematic code : yy_hold_char = ^@ yy_c_buf_p = 0 – mik Jan 18 '15 at 03:40

1 Answers1

1

I have answer of my own question. Here are some explanation of Solution

  1. I have two .Lex (Type1_Lex.l & Type2_Lex.l)and two .Yacc (Type1_Yacc.y & Type2_Yacc.y) code
  2. I am compiling all and relevant .c (Type1_Lex.c, Type2_Lex.c, Type1_Yacc.c & Type2_Yacc.v) and .h files are getting generated
  3. And further compilation of .c with generates Type1_Lex.o, Type2_Lex.o, Type1_Yacc.o Type2_Yacc.o
  4. Further I am putting all these object files in a single .a

The Problems are Here

  1. ... ld: Warning: size of symbol `yy_create_buffer' changed from 318 in libuperbe.a(TYPE1_Lex.o) to 208 in libxxx.a (TYPE2_Lex.o)

ld: Warning: size of symbol `yy_load_buffer_state' changed from 262 in libuperbe.a(TYPE1_Lex.o) to 146 in libxxx.a(TYPE2_Lex.o)

ld: Warning: size of symbol `yy_init_buffer' changed from 278 in libuperbe.a(TYPE1_Lex.o) to 164 in libxxx.a(TYPE2_Lex.o)

Some symbols are same in both generated .c (TYPE1_Lex.c & TYPE2_Lex.c)

  • When both object file bind in a single .a the similar (yy_create_buffer,yy_init_buffer,yy_load_buffer_state) symbols got overridden.

  • At the runtime when the methods yy_create_buffer(),yy_init_buffer(), yy_load_buffer_state() should be called defined in TYPE2_Lex.c but in actual those methods are called from the file TYPE1_Lex.c and the leads to the memory corruption some how.

  • For moving ahead I decided to use sed with following patterns :

Sed TYPE2_Lex.c with :

  • s/yy_create_buffer()/TYPE1_create_buffer/g
  • s/yy_init_buffer()/TYPE1_init_buffer/g
  • s/yy_load_buffer_state()/TYPE1_load_buffer_state/g

Sed TYPE2_Lex.c with

  • s/yy_create_buffer()/TYPE2_create_buffer/g
  • s/yy_init_buffer()/TYPE2_init_buffer/g
  • s/yy_load_buffer_state()/TYPE2_load_buffer_state/g

So that the Loader can easily differentiate the symbol. And at the run time confusion between the methods name become null.

After all these Step I am able to move ahead :) Thanks all for your help :)

mik
  • 73
  • 8
  • 1
    You should have mentioned this useful fact in your question. Anyway, you can change the prefix in generated code. For flex, use the flag `-PTYPE1` (or, in recent versions, `--prefix=TYPE1`) to change the prefix to `TYPE1`. For bison, use the flag `-pTYPE1` (or, in recent versions, `-Dapi.prefix=TYPE1`). – rici Jan 18 '15 at 16:54
  • @rici : I was not aware about such thing as I am very new for .Lex and .Yacc and your will help me further in learning the these Technologies. – mik Jan 19 '15 at 08:51