This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug driver/36968] New: [4.4 regression] malloc corruption building jv-convert.exe


When bootstrapping:

/bin/sh ./libtool --tag=GCJ --mode=link /mingw/src/gccf/gcc/gcj
-B/mingw/src/gcc
f/i386-pc-mingw32/libjava/ -B/mingw/src/gccf/gcc/
-L/mingw/src/gccf/i386-pc-ming
w32/libjava -ffloat-store -fomit-frame-pointer -Usun -fno-omit-frame-pointer -g 
-O2  -o jv-convert.exe --main=gnu.gcj.convert.Convert -rpath
/mingw/lib/gcc/i386
-pc-mingw32/4.4.0 -shared-libgcc   
-L/mingw/src/gccf/i386-pc-mingw32/libjava/.l
ibs libgcj.la 
libtool: link: /mingw/src/gccf/gcc/gcj
-B/mingw/src/gccf/i386-pc-mingw32/libjava
/ -B/mingw/src/gccf/gcc/ -ffloat-store -fomit-frame-pointer -Usun
-fno-omit-fram
e-pointer -g -O2 -o .libs/jv-convert.exe --main=gnu.gcj.convert.Convert
-shared-
libgcc  -L/mingw/src/gccf/i386-pc-mingw32/libjava/.libs
-L/mingw/src/gccf/i386-p
c-mingw32/libjava ./.libs/libgcj.a -L/mingw/lib/gcc/i386-pc-mingw32/4.4.0

gcj.exe: out of memory allocating 160 bytes
make[3]: *** [jv-convert.exe] Error 1

With mpatrol, we can isolate the actual bug:

MPATROL_OPTIONS='PAGEALLOC=LOWER' gdb /mingw/src/gccf/gcc/gcj

(gdb) set args -B/mingw/src/gccf/i386-pc-mingw32/libjava/
-B/mingw/src/gccf/gcc/ -ffloat-store -fomit-frame-pointer -Usun
-fno-omit-frame-pointer -g -O2 -o .libs/jv-convert.exe
--main=gnu.gcj.convert.Convert -shared-libgcc 
-L/mingw/src/gccf/i386-pc-mingw32/libjava/.libs
-L/mingw/src/gccf/i386-pc-mingw32/libjava ./.libs/libgcj.a
-L/mingw/lib/gcc/i386-pc-mingw32/4.4.0

(gdb) run
Program received signal SIGSEGV, Segmentation fault.                        
0x00414ed8 in spawn_script (executable=0x36a7000 "/mingw/src/gccf/gcc/as",  
    argv=0x12a3ffc, env=0x0, dwCreationFlags=0, si=0x27fb60, pi=0x27fb50)   
    at ../../svn/libiberty/pex-win32.c:654                                  
654                   *avhere = executable1;                                

(gdb) bt
#0  0x00414ed8 in spawn_script (                                                
    executable=0x36a7000 "/mingw/src/gccf/gcc/as", argv=0x12a3ffc, env=0x0,     
    dwCreationFlags=0, si=0x27fb60, pi=0x27fb50)                                
    at ../../svn/libiberty/pex-win32.c:654                                      
#1  0x00415113 in pex_win32_exec_child (obj=0x36aa000, flags=1,                 
    executable=0x36a7000 "/mingw/src/gccf/gcc/as", argv=0x12a4000, env=0x0,     
    in=0, out=1, errdes=2, toclose=-1, errmsg=0x27fcc8, err=0x27fdb4)           
    at ../../svn/libiberty/pex-win32.c:784                                      
#2  0x0041cc55 in pex_run_in_environment (obj=0x36aa000,                        
    flags=<value optimized out>,                                                
    executable=0x36a7000 "/mingw/src/gccf/gcc/as", argv=0x12a4000, env=0x0,     
    orig_outname=0x0, errname=0x0, err=0x27fdb4)                                
    at ../../svn/libiberty/pex-common.c:342                                     
#3  0x0041ce3f in pex_run (obj=0x36aa000, flags=1,                              
    executable=0x36a7000 "/mingw/src/gccf/gcc/as", argv=0x12a4000,              
    orig_outname=0x0, errname=0x0, err=0x27fdb4)                                
    at ../../svn/libiberty/pex-common.c:372                                     
#4  0x004040cb in execute () at ../../svn/gcc/gcc.c:3005                        
#5  0x0040d0be in lang_specific_pre_link () at ../../svn/gcc/java/jvspec.c:673  
#6  0x0040c42c in main (argc=1852400220, argv=0x68735c)                         
    at ../../svn/gcc/gcc.c:6825                                                 

The problem is clearly on pex-win32.c:646:

const char ** avhere = (const char **) --argv;

Then we hit the fault a few statements down at 654:

*avhere = executable1;

This is writing at (argv-1) which overrides the heap block header and causes
the corruption.

I'm going to look at this more tomorrow and see if I can figure out why its
doing this.  I'm a little curious how this code has been like this since 2005
without ever causing trouble before.


-- 
           Summary: [4.4 regression] malloc corruption building jv-
                    convert.exe
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: driver
        AssignedTo: aaronavay62 at aaronwl dot com
        ReportedBy: aaronavay62 at aaronwl dot com
  GCC host triplet: i386-pc-mingw32
OtherBugsDependingO 36216
             nThis:


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36968


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]