Closed GoogleCodeExporter closed 8 years ago
r601 works for me on OS X 10.6.8
Original comment by dwhall...@gmail.com
on 6 Oct 2013 at 4:48
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
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
Nice find mark. I've added the fix in r602.
Original comment by zik.sale...@gmail.com
on 14 Oct 2013 at 11:38
Original issue reported on code.google.com by
m...@heilpern.com
on 30 Aug 2013 at 2:58