* SegFault will importing some files from OpenOffice
@ 2000-12-23 7:43 Kevin B. Hendricks
2000-12-23 14:05 ` Ben Elliston
0 siblings, 1 reply; 13+ messages in thread
From: Kevin B. Hendricks @ 2000-12-23 7:43 UTC (permalink / raw)
To: sourcenav
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SegFault will importing some files from OpenOffice
2000-12-23 7:43 SegFault will importing some files from OpenOffice Kevin B. Hendricks
@ 2000-12-23 14:05 ` Ben Elliston
2000-12-23 14:48 ` Kevin B. Hendricks
0 siblings, 1 reply; 13+ messages in thread
From: Ben Elliston @ 2000-12-23 14:05 UTC (permalink / raw)
To: khendricks; +Cc: sourcenav
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SegFault will importing some files from OpenOffice
2000-12-23 14:05 ` Ben Elliston
@ 2000-12-23 14:48 ` Kevin B. Hendricks
2000-12-23 16:06 ` Ben Elliston
0 siblings, 1 reply; 13+ messages in thread
From: Kevin B. Hendricks @ 2000-12-23 14:48 UTC (permalink / raw)
To: Ben Elliston, khendricks; +Cc: sourcenav
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SegFault will importing some files from OpenOffice
2000-12-23 14:48 ` Kevin B. Hendricks
@ 2000-12-23 16:06 ` Ben Elliston
[not found] ` <00122611294700.12215@localhost>
0 siblings, 1 reply; 13+ messages in thread
From: Ben Elliston @ 2000-12-23 16:06 UTC (permalink / raw)
To: khendricks; +Cc: sourcenav
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SegFault will importing some files from OpenOffice
[not found] ` <00122611294700.12215@localhost>
@ 2000-12-26 11:44 ` Kevin B. Hendricks
2000-12-26 12:52 ` Syd Polk
2000-12-26 14:09 ` Ben Elliston
2000-12-27 15:17 ` SegFault will importing some files from OpenOffice Ben Elliston
1 sibling, 2 replies; 13+ messages in thread
From: Kevin B. Hendricks @ 2000-12-26 11:44 UTC (permalink / raw)
To: khendricks; +Cc: sourcenav
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SegFault will importing some files from OpenOffice
2000-12-26 11:44 ` Kevin B. Hendricks
@ 2000-12-26 12:52 ` Syd Polk
2000-12-26 14:09 ` Ben Elliston
1 sibling, 0 replies; 13+ messages in thread
From: Syd Polk @ 2000-12-26 12:52 UTC (permalink / raw)
To: khendricks, khendricks; +Cc: sourcenav
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SegFault will importing some files from OpenOffice
2000-12-26 11:44 ` Kevin B. Hendricks
2000-12-26 12:52 ` Syd Polk
@ 2000-12-26 14:09 ` Ben Elliston
2000-12-26 14:14 ` Kevin B. Hendricks
1 sibling, 1 reply; 13+ messages in thread
From: Ben Elliston @ 2000-12-26 14:09 UTC (permalink / raw)
To: khendricks; +Cc: sourcenav
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SegFault will importing some files from OpenOffice
2000-12-26 14:09 ` Ben Elliston
@ 2000-12-26 14:14 ` Kevin B. Hendricks
2000-12-27 15:17 ` Ben Elliston
0 siblings, 1 reply; 13+ messages in thread
From: Kevin B. Hendricks @ 2000-12-26 14:14 UTC (permalink / raw)
To: Ben Elliston, khendricks; +Cc: sourcenav
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SegFault will importing some files from OpenOffice
2000-12-26 14:14 ` Kevin B. Hendricks
@ 2000-12-27 15:17 ` Ben Elliston
2000-12-28 6:35 ` Kevin B. Hendricks
2000-12-28 19:29 ` Found buffer overflow, hack patch attached Kevin B. Hendricks
0 siblings, 2 replies; 13+ messages in thread
From: Ben Elliston @ 2000-12-27 15:17 UTC (permalink / raw)
To: khendricks; +Cc: sourcenav
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SegFault will importing some files from OpenOffice
[not found] ` <00122611294700.12215@localhost>
2000-12-26 11:44 ` Kevin B. Hendricks
@ 2000-12-27 15:17 ` Ben Elliston
1 sibling, 0 replies; 13+ messages in thread
From: Ben Elliston @ 2000-12-27 15:17 UTC (permalink / raw)
To: khendricks; +Cc: sourcenav
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SegFault will importing some files from OpenOffice
2000-12-27 15:17 ` Ben Elliston
@ 2000-12-28 6:35 ` Kevin B. Hendricks
2000-12-28 9:24 ` Kevin B. Hendricks
2000-12-28 19:29 ` Found buffer overflow, hack patch attached Kevin B. Hendricks
1 sibling, 1 reply; 13+ messages in thread
From: Kevin B. Hendricks @ 2000-12-28 6:35 UTC (permalink / raw)
To: Ben Elliston, khendricks; +Cc: sourcenav
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: SegFault will importing some files from OpenOffice
2000-12-28 6:35 ` Kevin B. Hendricks
@ 2000-12-28 9:24 ` Kevin B. Hendricks
0 siblings, 0 replies; 13+ messages in thread
From: Kevin B. Hendricks @ 2000-12-28 9:24 UTC (permalink / raw)
To: khendricks; +Cc: sourcenav
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Found buffer overflow, hack patch attached
2000-12-27 15:17 ` Ben Elliston
2000-12-28 6:35 ` Kevin B. Hendricks
@ 2000-12-28 19:29 ` Kevin B. Hendricks
1 sibling, 0 replies; 13+ messages in thread
From: Kevin B. Hendricks @ 2000-12-28 19:29 UTC (permalink / raw)
To: Ben Elliston, khendricks; +Cc: sourcenav
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2000-12-28 19:29 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-12-23 7:43 SegFault will importing some files from OpenOffice Kevin B. Hendricks
2000-12-23 14:05 ` Ben Elliston
2000-12-23 14:48 ` Kevin B. Hendricks
2000-12-23 16:06 ` Ben Elliston
[not found] ` <00122611294700.12215@localhost>
2000-12-26 11:44 ` Kevin B. Hendricks
2000-12-26 12:52 ` Syd Polk
2000-12-26 14:09 ` Ben Elliston
2000-12-26 14:14 ` Kevin B. Hendricks
2000-12-27 15:17 ` Ben Elliston
2000-12-28 6:35 ` Kevin B. Hendricks
2000-12-28 9:24 ` Kevin B. Hendricks
2000-12-28 19:29 ` Found buffer overflow, hack patch attached Kevin B. Hendricks
2000-12-27 15:17 ` SegFault will importing some files from OpenOffice Ben Elliston
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).