Skip to contentSkip to conversation

segfault with backtrace and information

DISCUSSION Peter Jay Salzman 2 participants 3 messages Dec 8, 2002 – Dec 14, 2002

lore
Share & tools
lore
#0 lore raw

dosemu consistantly segfaults on one of my machines.

i'm using version 1.1.3.7 with the experimental sound patches under vanilla 2.4.20. machine arch is AMD athlon 1st generation 1.4 GHz with a 1st generation ATI radeon.

the machine didn't oops.

backtrace is follows:

lucifer# gdb /usr/local/bin/dos-debug (gdb) run
Starting program: /usr/local/bin/dos-debug Linux kernel 2.4.19; CPU speed is 1300264000 Hz Dosemu-1.1.3.7 Running on CPU=586, FPU=1

Program received signal SIGSEGV, Segmentation fault. 0x080aeda4 in real_yylex (yylval=0x4d003b) at lexer.l:707
707 yylval->s_value = strdup(&yytext[1]);
(gdb) bt
#0 0x080aeda4 in real_yylex (yylval=0x4d003b) at lexer.l:707 #1 0x08107251 in _IO_stdin_used ()

the area of code:

   (gdb) l 707
   702     {STRQUOTELESS}          MAY_BEFORME {
   703                               yylval->s_value = strdup(yytext);
   704                               EXPRTYPE(yylval->s_value) = TYPE_STRQUOTELESS;
   705                               return(STRING); }
   706     ${IDENT}                MAY_BE {
   707                                     yylval->s_value = strdup(&yytext[1]);
   708                                     EXPRTYPE(yylval->s_value) =
   TYPE_STRQUOTELESS;
   709                                     return(VARIABLE);
   710                             }
   711     $${IDENT}               MAY_BE { enter_macrofile(&yytext[2]);}

(gdb) printf "%s", &yytext[1]
_DOSEMU_ORIG_PATH(gdb)

(gdb) printf "%s", strdup(&yytext[1])
_DOSEMU_ORIG_PATH(gdb)

(gdb) printf "%s", yylval->s_value
Cannot access memory at address 0x4d003b

(gdb) printf "%s", yylval->s_value
Cannot access memory at address 0x4d003b

(gdb) ptype yylval->s_value
type = char *

(gdb) p yylval->s_value = strdup(&yytext[1])
Cannot access memory at address 0x4d003b

i'm a bit confused at this point. it looks like the address returned by strdup is no good, but i have no idea how that can be.

strace provides no help:

write(2, "Linux kernel 2.4.19; CPU speed i"..., 48) = 48 write(2, "Dosemu-1.1.3.7 Running on CPU=58"..., 41) = 41
brk(0x832d000) = 0x832d000
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

ltrace output pretty much confirms what the backtrace said:

   strcmp("parser_version_3", "h_lucifer")           = 8
   strcmp("parser_version_3", "c_all")               = 13
   strcmp("parser_version_3", "parser_version_3")    = 0
   strchr(""/etc/dosemu.conf"", '\n')                = NULL

__strdup(0x08329490, 10, 0, 0x080aa782, 0x08107251) = 0x0832cb78 --- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

dosemu works fine on my other machines. this seems to be a problem with this machine only, but nothing about this looks arch dependent to me.

any suggestions?

pete

Signature · 1 line
Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D
#1 lore raw

begin Peter Jay Salzman <[email protected]>

Quoted 5 lines

dosemu consistantly segfaults on one of my machines.

i'm using version 1.1.3.7 with the experimental sound patches under vanilla 2.4.20. machine arch is AMD athlon 1st generation 1.4 GHz with a 1st generation ATI radeon.

sorry, this machine is running vanilla 2.4.19, not 2.4.20.

pete

#2 lore raw
In reply to Peter Jay Salzman

Peter Jay Salzman said :

Quoted 11 lines

dosemu consistantly segfaults on one of my machines.

the area of code:

   (gdb) l 707
   702     {STRQUOTELESS}          MAY_BEFORME {
   703                               yylval->s_value = strdup(yytext);
   704                               EXPRTYPE(yylval->s_value) = TYPE_STRQUOTELESS;
   705                               return(STRING); }

[snip]

Hi,

I encounter the same bug using gcc 3.2.2, bison 1.75 and flex 2.5.4

I found that parser.c calls yylex without arguments, whereas lex.yy.c defines yylex to be of type yylex(YYTYPE *yylval).

That means that bison does not build a pure parser, although YYPURE was defined.

I do not know exactly whether it is gcc or bison that is behaving wrong, but inserting the line :

%pure-parser

in the file parser.y.in (after the line: %start lines, for example) was sufficient for me to solve this problem.

Regards,
Emmanuel