SegFault will importing some files from OpenOffice

[Kevin B. Hendricks]

Hi Ben,

Here is the output of gdb from the 
following command:

/usr/local/bin/cbrowser -t -n .snprj/kbhend7 -y 
/home/kbhend/.snprj/tmp_IpouXw -p /usr/local/bin/dbimp -x /tmp/tmp_HK4r6u -c 
300 -H localhost -P 17948 -I /home/kbhend/.snprj/tmp_l4vDGy

Here is the backtrace from the very last instruction before the call into the 
weeds:

(gdb) bt
#0  f_ReadFile (fd=0)
    at ../../../../../snavigator/parsers/cpp/cpplib/cplex.c:204
#1  0x100022f4 in start_parser (
    filename_a=0x7fffe918 "temp/InstallEnvironment.hpp", is_cpp=1, 
    pf_hig=0x2000, mode=0) at ../../../../snavigator/parsers/cpp/cparser.c:388
#2  0x10015994 in main (argc=271428296, argv=0x100c0000)
    at ../../../../snavigator/parsers/cpp/skeleton.c:289
#3  0xfe9a73c in __libc_start_main (argc=18, argv=0x7ffff9a4, 
envp=0x7ffff9f0, 
    auxvec=0x7ffffa64, rtld_fini=0x1a86, stinfo=0x100946d0, 
stack_on_entry=0x0)
    at ../sysdeps/powerpc/elf/libc-start.c:106


Here is me single stepping to exactly that point which occurs right before we 
call to Tcl_DStringAppend(&yybuf, buf, nbytes);


1464	}
(gdb) 
f_ReadFile (fd=0) at ../../../../../snavigator/parsers/cpp/cpplib/cplex.c:181
181	  while ((nbytes = read(fd, buf, sizeof(buf))) > 0)
(gdb) 
206	    }
(gdb) 
184	      if (encoding != NULL)
(gdb) 
204	  	  Tcl_DStringAppend(&yybuf, buf, nbytes);


Here is what is being passed at this time:

(gdb) print (Tcl_DString)yybuf
$2 = {string = 0x10284430 "", length = 0, spaceAvl = 200, 
  staticSpace = '\000' <repeats 199 times>}

(gdb) print buf
$3 = "#ifndef _COM_SUN_STAR_SETUP_INSTALLENVIRONMENT_HPP_\n#define 
_COM_SUN_STAR_SETUP_INSTALLENVIRONMENT_HPP_\n\n#ifndef 
_COM_SUN_STAR_SETUP_INSTALLENVIRONMENT_HDL_\n#include 
<com/sun/star/setup/InstallEnviron"...

(gdb) print nbytes
$4 = 6790

It looks like we are trying to allocate an additional 6790 bytes.

I think previous to this some buffer has overflowed and corrupted the stack 
but I can't seem to find where yet:

When we do one more step we end up never reaching Tcl_DStringAppend() but 
instead going into the weeds (or the weeds were written over the position of 
the Tcl_DStringAppend() location).  I think the latter case is more likely 
since this routine works every single other time it is called.

Now if I can only find the overflow that writing garbage into executable code 
I will be in business.

(gdb) step

Program received signal SIGSEGV, Segmentation fault.
0x74725068 in ?? ()
(gdb) 

Still looking.  

Any ideas of where to look for buffer overflows would be greatly appreciated.

Thanks,

Kevin
---
Kevin B. Hendricks, Associate Professor
Operations and Information Technology
Richard Ivey School of Business, UWO, London ON, CANADA
(519) 661-3874