SegFault will importing some files from OpenOffice

SegFault will importing some files from OpenOffice

[Kevin B. Hendricks]

Hi,

I recently joined the OpenOffice project to help with the ppc linux port.  
The source code is huge and I decided I finally needed something to help me 
find functions, etc. 

I chose SourceNavigator and built it.

Unfortunately, during the initial project import, both of the attached header 
files created a SIGSEGV.  I continued the import after each one.  Both files 
seems to show functions with very very long arguments lists.

Is there some hard coded limit I have reached here?

The files are attached for your own testing in case they help.

Thanks,

Kevin
 
---
Kevin B. Hendricks, Associate Professor
Operations and Information Technology
Richard Ivey School of Business, UWO, London ON, CANADA
(519) 661-3874
/*************************************************************************
 *
 *  $RCSfile: undgraut.hxx,v $
 *
 *  $Revision: 1.1.1.1 $
 *
 *  last change: $Author: hr $ $Date: 2000/09/18 16:46:30 $
 *
 *  The Contents of this file are made available subject to the terms of
 *  either of the following licenses
 *
 *         - GNU Lesser General Public License Version 2.1
 *         - Sun Industry Standards Source License Version 1.1
 *
 *  Sun Microsystems Inc., October, 2000
 *
 *  GNU Lesser General Public License Version 2.1
 *  =============================================
 *  Copyright 2000 by Sun Microsystems, Inc.
 *  901 San Antonio Road, Palo Alto, CA 94303, USA
 *
 *  This library is free software; you can redistribute it and/or
 *  modify it under the terms of the GNU Lesser General Public
 *  License version 2.1, as published by the Free Software Foundation.
 *
 *  This library is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 *  Lesser General Public License for more details.
 *
 *  You should have received a copy of the GNU Lesser General Public
 *  License along with this library; if not, write to the Free Software
 *  Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 *  MA  02111-1307  USA
 *
 *
 *  Sun Industry Standards Source License Version 1.1
 *  =================================================
 *  The contents of this file are subject to the Sun Industry Standards
 *  Source License Version 1.1 (the "License"); You may not use this file
 *  except in compliance with the License. You may obtain a copy of the
 *  License at http://www.openoffice.org/license.html .
 *
 *  Software provided under this License is provided on an "AS IS" basis,
 *  WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING,
 *  WITHOUT LIMITATION, WARRANTIES THAT THE SOFTWARE IS FREE OF DEFECTS,
 *  MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE, OR NON-INFRINGING.
 *  See the License for the specific provisions governing your rights and
 *  obligations concerning the Software.
 *
 *  The Initial Developer of the Original Code is: Sun Microsystems, Inc.
 *
 *  Copyright: 2000 by Sun Microsystems, Inc.
 *
 *  All Rights Reserved.
 *
 *  Contributor(s): _______________________________________
 *
 *
 ************************************************************************/

#ifndef _SCH_UNDGRAUT_HXX
#define _SCH_UNDGRAUT_HXX

#include "chtmodel.hxx"
#include "schundo.hxx"

/*************************************************************************
|*
|* Undo fuer Diagramm-Autopilot
|*
\************************************************************************/

class SchUndoDiagramAutoPilot : public SchUndoAction
{
private:
	SvxChartStyle eOldStyle;
//	long nOldGapWidth;
//	long nOldOverlap;
	long* pOldPieSegOfs;
	short nOldPieSegCount;
	BOOL bOldShowMainTitle;
	String aOldMainTitle;
	BOOL bOldShowSubTitle;
	String aOldSubTitle;
	BOOL bOldShowXAxisTitle;
	String aOldXAxisTitle;
	BOOL bOldShowYAxisTitle;
	String aOldYAxisTitle;
	BOOL bOldShowZAxisTitle;
	String aOldZAxisTitle;
	BOOL bOldShowXAxis;
	BOOL bOldShowXGridMain;
	BOOL bOldShowXGridHelp;
	BOOL bOldShowXDescr;
	BOOL bOldShowYAxis;
	BOOL bOldShowYGridMain;
	BOOL bOldShowYGridHelp;
	BOOL bOldShowYDescr;
	BOOL bOldShowZAxis;
	BOOL bOldShowZGridMain;
	BOOL bOldShowZGridHelp;
	BOOL bOldShowZDescr;
	BOOL bOldSwitchData;
	SvxChartLegendPos eOldLegendPos;

	SvxChartStyle eNewStyle;
//	long nNewGapWidth;
//	long nNewOverlap;
	long* pNewPieSegOfs;
	long nNewPieSegCount;
	BOOL bNewShowMainTitle;
	String aNewMainTitle;
	BOOL bNewShowSubTitle;
	String aNewSubTitle;
	BOOL bNewShowXAxisTitle;
	String aNewXAxisTitle;
	BOOL bNewShowYAxisTitle;
	String aNewYAxisTitle;
	BOOL bNewShowZAxisTitle;
	String aNewZAxisTitle;
	BOOL bNewShowXAxis;
	BOOL bNewShowXGridMain;
	BOOL bNewShowXGridHelp;
	BOOL bNewShowXDescr;
	BOOL bNewShowYAxis;
	BOOL bNewShowYGridMain;
	BOOL bNewShowYGridHelp;
	BOOL bNewShowYDescr;
	BOOL bNewShowZAxis;
	BOOL bNewShowZGridMain;
	BOOL bNewShowZGridHelp;
	BOOL bNewShowZDescr;
	BOOL bNewSwitchData;
	BOOL bNewShowLegend;

public:
	TYPEINFO();

	SchUndoDiagramAutoPilot(ChartModel& rChDoc,
							SvxChartStyle eOldStl,/* long nOldGap,
							long nOldOver, */long* pOldSegOfs,
							short nOldSegCount,
							BOOL bOldShowMain, const String& rOldMain,
							BOOL bOldShowSub, const String& rOldSub,
							BOOL bOldShowXAxis, const String& rOldXAxis,
							BOOL bOldShowYAxis, const String& rOldYAxis,
							BOOL bOldShowZAxis, const String& rOldZAxis,
							BOOL bOldXAxis, BOOL bOldXGridMain,
							BOOL bOldXGridHelp, BOOL bOldXDescr,
							BOOL bOldYAxis, BOOL bOldYGridMain,
							BOOL bOldYGridHelp, BOOL bOldYDescr,
							BOOL bOldZAxis, BOOL bOldZGridMain,
							BOOL bOldZGridHelp, BOOL bOldZDescr,
							BOOL bOldSwitch, SvxChartLegendPos eOldLegPos,
							SvxChartStyle eNewStl,/* long nNewGap,
							long nNewOver, */long* pNewSegOfs,
							short nNewSegCount,
							BOOL bNewShowMain, const String& rNewMain,
							BOOL bNewShowSub, const String& rNewSub,
							BOOL bNewShowXAxis, const String& rNewXAxis,
							BOOL bNewShowYAxis, const String& rNewYAxis,
							BOOL bNewShowZAxis, const String& rNewZAxis,
							BOOL bNewXAxis, BOOL bNewXGridMain,
							BOOL bNewXGridHelp, BOOL bNewXDescr,
							BOOL bNewYAxis, BOOL bNewYGridMain,
							BOOL bNewYGridHelp, BOOL bNewYDescr,
							BOOL bNewZAxis, BOOL bNewZGridMain,
							BOOL bNewZGridHelp, BOOL bNewZDescr,
							BOOL bNewSwitch, BOOL bNewLegend) :
		SchUndoAction(rChDoc),
		eOldStyle(eOldStl),
//		nOldGapWidth(nOldGap),
//		nOldOverlap(nOldOver),
		pOldPieSegOfs(pOldSegOfs),
		nOldPieSegCount(nOldSegCount),
		bOldShowMainTitle(bOldShowMain),
		aOldMainTitle(rOldMain),
		bOldShowSubTitle(bOldShowSub),
		aOldSubTitle(rOldSub),
		bOldShowXAxisTitle(bOldShowXAxis),
		aOldXAxisTitle(rOldXAxis),
		bOldShowYAxisTitle(bOldShowYAxis),
		aOldYAxisTitle(rOldYAxis),
		bOldShowZAxisTitle(bOldShowZAxis),
		aOldZAxisTitle(rOldZAxis),
		bOldShowXAxis(bOldXAxis),
		bOldShowXGridMain(bOldXGridMain),
		bOldShowXGridHelp(bOldXGridHelp),
		bOldShowXDescr(bOldXDescr),
		bOldShowYAxis(bOldYAxis),
		bOldShowYGridMain(bOldYGridMain),
		bOldShowYGridHelp(bOldYGridHelp),
		bOldShowYDescr(bOldYDescr),
		bOldShowZAxis(bOldZAxis),
		bOldShowZGridMain(bOldZGridMain),
		bOldShowZGridHelp(bOldZGridHelp),
		bOldShowZDescr(bOldZDescr),
		bOldSwitchData(bOldSwitch),
		eOldLegendPos(eOldLegPos),
		eNewStyle(eNewStl),
//		nNewGapWidth(nNewGap),
//		nNewOverlap(nNewOver),
		pNewPieSegOfs(pNewSegOfs),
		nNewPieSegCount(nNewSegCount),
		bNewShowMainTitle(bNewShowMain),
		aNewMainTitle(rNewMain),
		bNewShowSubTitle(bNewShowSub),
		aNewSubTitle(rNewSub),
		bNewShowXAxisTitle(bNewShowXAxis),
		aNewXAxisTitle(rNewXAxis),
		bNewShowYAxisTitle(bNewShowYAxis),
		aNewYAxisTitle(rNewYAxis),
		bNewShowZAxisTitle(bNewShowZAxis),
		aNewZAxisTitle(rNewZAxis),
		bNewShowXAxis(bNewXAxis),
		bNewShowXGridMain(bNewXGridMain),
		bNewShowXGridHelp(bNewXGridHelp),
		bNewShowXDescr(bNewXDescr),
		bNewShowYAxis(bNewYAxis),
		bNewShowYGridMain(bNewYGridMain),
		bNewShowYGridHelp(bNewYGridHelp),
		bNewShowYDescr(bNewYDescr),
		bNewShowZAxis(bNewZAxis),
		bNewShowZGridMain(bNewZGridMain),
		bNewShowZGridHelp(bNewZGridHelp),
		bNewShowZDescr(bNewZDescr),
		bNewSwitchData(bNewSwitch),
		bNewShowLegend(bNewLegend) {}
	virtual ~SchUndoDiagramAutoPilot();

	virtual void Undo();
	virtual void Redo();

	virtual BOOL CanRepeat(SfxRepeatTarget& rView) const;
};

#endif	// _SCH_UNDGRAUT_HXX

Re: SegFault will importing some files from OpenOffice

[Ben Elliston]

Hi Kevin,

   Unfortunately, during the initial project import, both of the attached
   header files created a SIGSEGV.  I continued the import after each
   one.  Both files seems to show functions with very very long arguments
   lists.

I parsed both of these files using S-N 4.52 on a Red Hat Linux 7 system and
encountered no problems.  What version of S-N are you using and on what
platform are you running it?

What do you get if you do this?

	$ echo InstallEnvironment.hpp undgraut.hxx > file.list
	$ gdb install/bin/cbrowser
	(gdb) run -p /bin/cat -y file.list

This will enable you to catch any seg faults and examine the stack
backtrace, etc. using GDB.

Ben

Re: SegFault will importing some files from OpenOffice

[Kevin B. Hendricks]

Hi Thanks for responding.

> I parsed both of these files using S-N 4.52 on a Red Hat Linux 7 system and
> encountered no problems.  What version of S-N are you using and on what
> platform are you running it?

4.5.2 downloaded and built from source today with the pallas patch installed 
for macros.

Platform is ppc linux glibc-2.1.3

> What do you get if you do this?
> 
> 	$ echo InstallEnvironment.hpp undgraut.hxx > file.list
> 	$ gdb install/bin/cbrowser
> 	(gdb) run -p /bin/cat -y file.list
> 
> This will enable you to catch any seg faults and examine the stack
> backtrace, etc. using GDB.

Unfortunately, this shows no problems or seg-faults (program ended normally).
So the problem only seems to occur when imported as part of the entire 
openoffice tree.

Can I do the same thing within gdb on the entire tree?

Thanks,

Kevin


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

Re: SegFault will importing some files from OpenOffice

[Ben Elliston]

Hi,

   > What do you get if you do this?
   >
   > 	$ echo InstallEnvironment.hpp undgraut.hxx > file.list
   > 	$ gdb install/bin/cbrowser
   > 	(gdb) run -p /bin/cat -y file.list
   >
   > This will enable you to catch any seg faults and examine the stack
   > backtrace, etc. using GDB.

   Unfortunately, this shows no problems or seg-faults (program ended
   normally). So the problem only seems to occur when imported as part of
   the entire openoffice tree.

   Can I do the same thing within gdb on the entire tree?

Yes.  Create your "manifest" by running:

	$ find /path/to/src -type f > file.list

And run again as above.  Good luck!

Ben

Re: SegFault will importing some files from OpenOffice

[Kevin B. Hendricks]

Hi Ben,

> Okay, this is not the same error as I reported before, but the following 
> (attached) file causes the cbrowser to hang in fread (backtrace inserted 
> below).

I found about 3 or 4 files that cause hangs.  Most of them are makefiles of 
some sort.  I would guess since I see no hangs under snavigator that these 
files are recongnized as non-source related files and that they are not added 
to the database of files to process.

By the way, once I remove all of the hanging files, cbrowser processes the 
complete list of files with no failures.  However, each and every time I 
start up snavigator and have it import the openoffice-613 source tree it will 
repeatedly segfault on the exact same files each time.

So there must be something different about how cbrowser is processing the 
files when handed to it by hyper /dbimp than when handed to it by cat?

I tried running hyper inside gdb and then setting gdb follow-fork-mode child 
but hyper repeatedly forks children to run cbrowser and I simply can't catch 
the error (I have to manually attach gdb to each forked process and I can't 
simply keep up).

Is there some other way to debug this?  Would an strace -f output help at all?

Thanks,

Kevin

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

Re: SegFault will importing some files from OpenOffice

[Syd Polk]

At 02:45 PM 12/26/00 -0500, Kevin B. Hendricks wrote:
>Hi Ben,
>
> > Okay, this is not the same error as I reported before, but the following
> > (attached) file causes the cbrowser to hang in fread (backtrace inserted
> > below).
>
>I found about 3 or 4 files that cause hangs.  Most of them are makefiles of
>some sort.  I would guess since I see no hangs under snavigator that these
>files are recongnized as non-source related files and that they are not added
>to the database of files to process.

Hmm. You should check your sn_prop.cfg files and make sure that your 
extensions are correct to your C parser.


>By the way, once I remove all of the hanging files, cbrowser processes the
>complete list of files with no failures.  However, each and every time I
>start up snavigator and have it import the openoffice-613 source tree it will
>repeatedly segfault on the exact same files each time.
>
>So there must be something different about how cbrowser is processing the
>files when handed to it by hyper /dbimp than when handed to it by cat?
>
>I tried running hyper inside gdb and then setting gdb follow-fork-mode child
>but hyper repeatedly forks children to run cbrowser and I simply can't catch
>the error (I have to manually attach gdb to each forked process and I can't
>simply keep up).
>
>Is there some other way to debug this?  Would an strace -f output help at all?
>
>Thanks,
>
>Kevin
>
>---
>Kevin B. Hendricks, Associate Professor
>Operations and Information Technology
>Richard Ivey School of Business, UWO, London ON, CANADA
>(519) 661-3874

Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Re: SegFault will importing some files from OpenOffice

[Ben Elliston]

Hi Kevin,

   I found about 3 or 4 files that cause hangs.  Most of them are
   makefiles of some sort.  I would guess since I see no hangs under
   snavigator that these files are recongnized as non-source related
   files and that they are not added to the database of files to process.

I think you're correct.

   By the way, once I remove all of the hanging files, cbrowser processes
   the complete list of files with no failures.  However, each and every
   time I start up snavigator and have it import the openoffice-613
   source tree it will repeatedly segfault on the exact same files each
   time.

Then perhaps the problem is elsewhere (ie. in dbimp).  The children work
something like this:

	hyper
	|
	`- cbrowser  <=
	   |          || pipe
	   `- dbimp  <=

cbrowser emits symbol information which `dbimp' imports into the database.

   I tried running hyper inside gdb and then setting gdb follow-fork-mode
   child but hyper repeatedly forks children to run cbrowser and I simply
   can't catch the error (I have to manually attach gdb to each forked
   process and I can't simply keep up).

That surprises me.  It ought to have caught the problem.

   Is there some other way to debug this?  Would an strace -f output help
   at all?

Yes, or ltrace, if you have it, would be better.

Ben

Re: SegFault will importing some files from OpenOffice

[Kevin B. Hendricks]

Hi Ben,

Would try the following for me (this fails on my system)

1. Copy those two original files I gave you into some directory (in my case I 
used temp/)

2. Then run snavigator and indicate a new project and have it import temp/

This causes a segfault immediately for me.
cbrowser has no problem with this so it must be dbimp that is seg-faulting 
which explains why I haven't been able to catch it when running cbrowser!
 
> Then perhaps the problem is elsewhere (ie. in dbimp).  The children work
> something like this:
> 
> 	hyper
> 	|
> 	`- cbrowser  <=
> 	   |          || pipe
> 	   `- dbimp  <=
> 
> cbrowser emits symbol information which `dbimp' imports into the database.

 
> Yes, or ltrace, if you have it, would be better.

I don't seem to have ltrace but I do think I can get a backtrace using gdb 
now that I have a much smaller testcase to play with.

Thanks,

Kevin

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

Re: SegFault will importing some files from OpenOffice

[Ben Elliston]

Hi Kevin,

   This causes a segfault immediately for me. cbrowser has no problem
   with this so it must be dbimp that is seg-faulting which explains why
   I haven't been able to catch it when running cbrowser!

I tried what you suggested -- creating a new project with only those two
source files.  No problem; it parsed successfully.  This is using a quite
recent version of S-N on my Red Hat Linux 7 system.

Cheers, Ben

Re: SegFault will importing some files from OpenOffice

[Ben Elliston]

Kevin,

   Okay, this is not the same error as I reported before, but the
   following (attached) file causes the cbrowser to hang in fread
   (backtrace inserted below).

I'm not surprised.  It's a HTML document.  Why is S-N matching `.htm' files
as being C/C++ source?  It shouldn't do that.

Ben

Re: SegFault will importing some files from OpenOffice

[Kevin B. Hendricks]

Hi Ben,

Thanks for trying.

> I tried what you suggested -- creating a new project with only those two
> source files.  No problem; it parsed successfully.  This is using a quite
> recent version of S-N on my Red Hat Linux 7 system.

I edited the tcl8.1/unix/tclUnixPipe.c and after the fork added a sleep for 
45 seconds if the environment variable DSLEEP is set.

Unfortunately, although I have time to attach gdb to each forked process, the 
segfault comes from executing garabage and there is no stack frame to back 
trace through.  It seems as if the exec command is loading garbage for some 
reason. 

There must be another "fork "someplace that I missed because I never see two 
forked processed (just the one since they execute so fast).  Does the dbimp 
or cbrowser code do forking too?

This could all be glibc or tools related on ppc.  I just can't figure out why 
it is dependent upon these specific text files to trigger the bug.

I will keep looking when I find some time to track this down and get it fixed.

Thanks for all your help.

Kevin

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

Re: 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

Found buffer overflow, hack patch attached

[Kevin B. Hendricks]

Hi Ben,

I found the buffer overflow.  It happens in line 6171 in cparser.c in 
put_cross1().

It seems someone hardcoded tmp to be 1000 characters long which is too short 
to hold the function declaration info from the files I posted.  This ends up 
overwriting stack space which includes the return address thus the branch 
into the weeds was actually a return into the weeds.

Since one hardcoded size is just as bad as another, I felt what the hell and 
just multiplied it by 10.

You may want to calculate the length properly and malloc the appropriate size 
instead of this hard coded limit (or mine).

Anyway, the patch is attached.  Everything works now.

Thanks for your help.

Kevin

---
Kevin B. Hendricks, Associate Professor
Operations and Information Technology
Richard Ivey School of Business, UWO, London ON, CANADA
(519) 661-3874
--- snavigator/parsers/cpp/cparser.c.prev	Thu Dec 28 22:17:46 2000
+++ snavigator/parsers/cpp/cparser.c	Thu Dec 28 22:18:18 2000
@@ -6166,7 +6166,7 @@
    if( cross_ref_fp )
    {
       Tcl_DString utfString;
-      char tmp[1000];
+      char tmp[10000];
 
       sprintf(tmp,"%d;%d;%s;%d;%d;%d;%d;%ld;%s;%s;%s;%s;%s;%d;\n"
           , PAF_CROSS_REF_CPP