r581 and later failing on OS X

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Attempt to use pico r581 or later on OS X in interactive mode
Other modes are untested by me.

Entering the simplest line, such as "int i;" in interactive mode on r581 and 
later, causes a segmentation fault under OS X. Under Linux this does not happen.

Original issue reported on code.google.com by m...@heilpern.com on 30 Aug 2013 at 2:58

[GoogleCodeExporter]

r601 works for me on OS X 10.6.8

Original comment by dwhall...@gmail.com on 6 Oct 2013 at 4:48

[GoogleCodeExporter]

On OS X 10.8.5, the crash appears to be related to a failed attempt at printing 
an out of memory error (though it's entirely unclear why it would think there's 
no memory available!)

Marks-iMac:picoc-601 $ gdb picoc
GNU gdb 6.3.50-20050815 (Apple version gdb-1822) (Sun Aug  5 03:00:42 UTC 2012)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared 
libraries ... done

(gdb) run -i
Starting program: /Users/mark/Downloads/picoc-601/picoc -i
Reading symbols for shared libraries ++............................... done
starting picoc v2.2 beta rexported
picoc> int test;

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000000000000c
0x00007fff8cafb810 in putc ()
(gdb) up
#1  0x00000001000165bf in PrintCh (OutCh=105 'i', Stream=0x0) at 
cstdlib/stdio.c:721
721     putc(OutCh, Stream);
Current language:  auto; currently minimal
(gdb) p Stream
$1 = (FILE *) 0x0
(gdb) bt
#0  0x00007fff8cafb810 in putc ()
#1  0x00000001000165bf in PrintCh (OutCh=105 'i', Stream=0x0) at 
cstdlib/stdio.c:721
#2  0x00000001000123b2 in PrintSourceTextErrorLine (Stream=0x0, 
FileName=0x100114c60 "?-\021", SourceText=0x7fff5fbfe380 "int test;\n", Line=1, 
CharacterPos=1) at platform.c:111
#3  0x0000000100012f02 in LexFail (pc=0x7fff5fbfe700, Lexer=0x7fff5fbfe2a8, 
Message=0x10001bf4a "out of memory") at platform.c:183
#4  0x00000001000041d3 in LexTokenise (pc=0x7fff5fbfe700, Lexer=0x7fff5fbfe2a8, 
TokenLen=0x7fff5fbfe374) at lex.c:539
#5  0x00000001000044a2 in LexAnalyse (pc=0x7fff5fbfe700, FileName=0x100114c60 
"?-\021", Source=0x7fff5fbfe380 "int test;\n", SourceLen=10, 
TokenLen=0x7fff5fbfe374) at lex.c:606
#6  0x00000001000047b6 in LexGetRawToken (Parser=0x7fff5fbfe6a8, 
Value=0x7fff5fbfe658, IncPos=1) at lex.c:672
#7  0x000000010000514a in LexGetToken (Parser=0x7fff5fbfe6a8, 
Value=0x7fff5fbfe658, IncPos=1) at lex.c:893
#8  0x0000000100005daf in ParseStatement (Parser=0x7fff5fbfe6a8, 
CheckTrailingSemicolon=1) at parse.c:583
#9  0x0000000100008614 in PicocParseInteractiveNoStartPrompt 
(pc=0x7fff5fbfe740, EnableDebugger=1) at parse.c:990
#10 0x00000001000086a3 in PicocParseInteractive (pc=0x7fff5fbfe740) at 
parse.c:1005
#11 0x000000010000105a in main (argc=2, argv=0x7fff5fbffb58) at picoc.c:43

Original comment by m...@heilpern.com on 14 Oct 2013 at 3:12

[GoogleCodeExporter]

I've found the root cause of this. It has nothing to do with a true out of 
memory situation, the problem is the "pc" pointer address is being changed -- 
just slightly, and the cause is PlatformGetLine() in platform/platform_unix.c.

The function PlatformGetLine() is passed a buffer (Buf) and the length of that 
buffer (MaxLen). The function then fills that buffer using the readline() 
function, and wants to NULL-terminate the buffer… so it performs: Buf[MaxLen] 
= '\0';
The problem is the length of the buffer is only MaxLen, comprising of elements 
between 0 and (MaxLen-1) inclusive -- so this writes a NULL _beyond_ the buffer.

In my stack trace above, you see that the "pc" pointer is 0x7fff5fbfe740 
towards the bottom of the stack, but at some point after entering 
LexGetRawToken (which reads from stdin eventually) the pointer has changed to 
0x7fff5fbfe700 -- the location of this pointer is immediately adjacent to the 
input buffer, and it is stored in little endian (LSB first), hence the overrun 
of writing NULL is disrupting its LSB.

Original comment by m...@heilpern.com on 14 Oct 2013 at 4:10

[GoogleCodeExporter]

Nice find mark. I've added the fix in r602.

Original comment by zik.sale...@gmail.com on 14 Oct 2013 at 11:38

• Changed state: Fixed