#118 SEGFAULT when using BSDL files

0.17
closed-fixed
nobody
None
5
2014-08-02
2014-07-25
No

Hardware is Terasic DE0-Nano, built-in usbblaster, FTDI driver

Executing the following causes a segfault:
cable usbblaster driver=ftdi
bsdl path .
detect

The attached BSDL is in the current directory (.)

Debugging the code reveals the problem to be in the generated vhdl_flex.c, line 1262:
while ( 1 ) / loops until end-of-file is reached /
{
yy_cp = yyg->yy_c_buf_p;

            /* Support of yytext. */
            *yy_cp = yyg->yy_hold_char;    // SEGFAULT 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 = yyg->yy_start;

Bison is 3.0.2 and Flex is 2.5.35.
Version is SVN 2041.
No idea how to fix it, I'm not a bison expert, but happy to test.

1 Attachments

Discussion

  • cioma

    cioma - 2014-07-27

    Had the same problem with r2041 and managed to track it down. The problem is in generated bsdl_bison.c and vhdl_bison.c: they have "priv_data" pointer assigned as "scanner" pointer in "yylex" which is wrong. If in both files you change:

    yychar = yylex (&yylval, priv_data);
    

    to

    yychar = yylex (&yylval, YYLEX_PARAM);
    

    Then recompile and it works fine. Perhaps someone knows how to fix the root-cause (makefiles?)

     
    Last edit: cioma 2014-07-27
  • Binary Logic

    Binary Logic - 2014-07-27

    Hi cioma, thanks for the awesome follow up. It did indeed fix the issue I reported. Unfortunately, there's further problems when I try to use the SVF player and get another core dump. This time in svf_flex.c line 3080. The buffer yyg->yy_c_buf_p has an invalid value. I tried following your pattern, but this is a flex file rather than bison, so it's a different fix. I'm trying to trace when this parameter gets set, but I'm not so good at this stuff.

    I created a patch file to fix the first issue noted above. It has to be applied after the first make, because the files to patch don't exist until bison has been run during the first make. Patch with "patch -p1 < patch.txt" then make again. It's a bandaid, but with the other problems I discovered later, it's not worth trying to fix up the source yet.

    I'll continue to try and work on svf_flex.c, but any help you can provide would be awesome.

     
  • Binary Logic

    Binary Logic - 2014-07-27

    Don't worry - I fixed it! I think it's the same problem you found. Line 1494 of svf_bison.c, chain is passed and it should be YYLEX_PARAM instead:


    Line: 1494
    yychar = yylex (&yylval, &yylloc, YYLEX_PARAM);

    I'll post the band-aid patch file when I have time - it's pretty late now.

     
  • cioma

    cioma - 2014-07-27

    Many thanks, Paul!

    Please do post a band-aid patch but I hope someone knowledgeable about lexers/makefiles would provide a patch for the root-cause. I'm just a bit surprised nobody discovered it before as it seems this bug has been there for some time. Perhaps it's tool dependent (I use Ubuntu 14.04 x64 with latest updates).

     
  • Binary Logic

    Binary Logic - 2014-07-28

    Cioma - I'll go one better, I've fixed the original Bison .y file. The weird thing is, if you look at commit 2040 the only change is to add the lines that I've now changed. I'm using the same version as you UB14.04 x64, w/Bison 3.0.2 and Flex 2.5.35. I would guess that the author of 2040 is using an older version of Bison. The issue seems to be a mismatch between Bison and Flex, and looking at the Bison changelog, there were a lot of changes between Bison 2.7.1 (Ubuntu 13.10) and Bison 3.0.2 (Ubuntu 14.04).

    Attached is the patch file. Go into the build directory (where autogen.sh is) and execute

    ./autogen.sh
    patch -p1 < newpatch.txt

    Autogen.sh needs to run first to create config.h so that I can update the version number with the custom tag. Seems to work great now and I've got the Python bindings working great too, which was my reason for trying to upgrade!

    I'll submit my change to vapier and ask if it's applicable for inclusion.

    Thanks heaps for your help. I wouldn't know where to start otherwise!

    Cheers

     
  • cioma

    cioma - 2014-07-28

    Thanks, Paul, your patch worked for me.

    Well, I'm an electronics engineer, not a programmer, so I've been printf'ing file handle numbers and pointer addresses for half a night to find it out :)

    It all began with the fact that bsdl2jtag compiled from SVN r2041 code was expecting data from STDIN instead of reading it from the provided filename. That was confirmed when I strace'd it. And then the fun began as I didn't care to refresh my gdb knowledge in order to debug it properly so I started reading code and inserting printf() :)

     
  • Mike Frysinger

    Mike Frysinger - 2014-07-29
    • status: open --> closed-fixed
     
  • Mike Frysinger

    Mike Frysinger - 2014-07-29

    i don't think defining %lex-param like that is intended (even if it does work). the documentation indicates it's supposed to be the same as %parse-param which means it takes a type decl. see also this posting:
    https://lists.gnu.org/archive/html/bug-bison/2014-02/msg00002.html

    i've largely deployed the same changes as suggested, but linked to the bison list and labeled it a hack :). please double check latest source still works.

    when i tested the code locally, i guess my c/h files weren't being properly regenerated.

     
  • cioma

    cioma - 2014-07-30

    Hi Mike,

    Works for me, many thanks!

     
  • Binary Logic

    Binary Logic - 2014-08-02

    Thanks so much Mike - I find flex/bison so confusing, but I'm glad we managed to iron this one out. The C and Python libraries are now accessible to my project - so incredibly useful. Thanks again.

     
  • Kolja Waschk

    Kolja Waschk - 2017-02-12
    • Group: 0.x --> 0.17
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks