You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Doug Alcorn <do...@lathi.net> on 2001/02/08 23:46:32 UTC
Segfault in ReaderMgr::createReader()
Our company is incorporating xerces into it's client/server app for
import/export of data. The app is written in C++ originally on win32,
but now ported to Linux/Solaris. Another team member did the
integration of xerces into our code. It all works like a champ on
win32. It mostly works under Linux as well. I'm not pretending to be
very XML smart. My real job is to do the Linux debugging.
The problem is fairly insidious because it only shows up when the app
is compiled with debugging turned off. Also, no core file is being
generated even though it segfaults. (I would love for someone to
enlighten me on when a core file is produced and when it isn't. BTW,
I tried running the process as root so that I was sure it would have
write privileges in whatever directory it was in).
Also note that the segfault doesn't turn up on every installation of
Linux. My own rh7 box with the infamous gcc/g++ (2.96-54) and
glibc/libstdc++ (2.1.92-14/2.96-54) doesn't crash regardless of
whether I have debuggin symbols compiled in or not. However, our
"build box" for non-rh7 binaries is a Debian potato with gcc/g++
2.95.2-13 and glibc 2.1.3-10. It consistently causes the crash, but
only if you compile without debug symbols. My guess is that the debug
symbols just give the run-away pointer more room to wander before he
violates his memory space.
So, my debugging method is to go through and wrap suspect function
calls in printf()s to see where the segfault is. So far, while
tedious, the crashing has been extremely consistent. I have tracked
the segfault to this manually created backtrace (I'm calling the
lowest function I've tracked it to cnotext 0 even though I'm not sure
that is the exact function the segfault is occuring in. It's just as
far as I've been able to track it):
#0 ReaderMgr::createReader(), internal/ReaderMgr.cpp:463
#1 DTDValidator::scanDocTypeDecl(),
validators/DTD/DTDValidator2.cpp:1456
#2 DTDValidator::scanDTD(), validators/DTD/DTDValidator.cpp:777
#3 XMLScanner::scanProlog(), internal/XMLScanner.cpp:1890
#4 XMLScanner::scanDocument(), internal/XMLScanner.cpp:285
#5 XMLScanner::scanDocument(), internal/XMLScanner.cpp:241
#6 SAXParser::parse(), parsers/SAXParser.cpp:368
#7 our code calling the parser
Note that the above line numbers are approximate due to the additions
or printfs()s and #include <stdio.h>.
The segfault in createReader is in this code:
,----[ ReaderMgr::createReader, lines 490 - 500 ]
| // Call the entity resolver interface to get an input source
| srcToFill = 0;
| if (fEntityHandler)
| {
| printf("starting to resolveEntity\n");
| srcToFill = fEntityHandler->resolveEntity
| (
| pubId
| , expSysId.getRawBuffer()
| );
| printf("done\n");
| }
`----
It never comes back from fEntityHandler->resolveEntity. My problem is
that I can't find the definition of resolveEntity. The only actual
definition I find is just { return 0; }.
Can anyone who understands this code help me?
--
(__) Doug Alcorn (mailto:doug@lathi.net http://www.lathi.net)
oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543
|_/ If you're a capitalist and you have the best goods and they're
free, you don't have to proselytize, you just have to wait.
Re: Segfault in ReaderMgr::createReader()
Posted by Kirk Wylie <ki...@radik.com>.
Upgrade your glibc. The current version of glibc you should be using (check
the RH7 updates page) is 2.2-9 or later. There are malloc problems in glibc
2.1.92 distributed by default.
Upgrade everything according to the RH7 update page and try again. That
fixed most of our RH7 porting issues.
Kirk Wylie
Doug Alcorn wrote:
>
> Our company is incorporating xerces into it's client/server app for
> import/export of data. The app is written in C++ originally on win32,
> but now ported to Linux/Solaris. Another team member did the
> integration of xerces into our code. It all works like a champ on
> win32. It mostly works under Linux as well. I'm not pretending to be
> very XML smart. My real job is to do the Linux debugging.
>
> The problem is fairly insidious because it only shows up when the app
> is compiled with debugging turned off. Also, no core file is being
> generated even though it segfaults. (I would love for someone to
> enlighten me on when a core file is produced and when it isn't. BTW,
> I tried running the process as root so that I was sure it would have
> write privileges in whatever directory it was in).
>
> Also note that the segfault doesn't turn up on every installation of
> Linux. My own rh7 box with the infamous gcc/g++ (2.96-54) and
> glibc/libstdc++ (2.1.92-14/2.96-54) doesn't crash regardless of
> whether I have debuggin symbols compiled in or not. However, our
> "build box" for non-rh7 binaries is a Debian potato with gcc/g++
> 2.95.2-13 and glibc 2.1.3-10. It consistently causes the crash, but
> only if you compile without debug symbols. My guess is that the debug
> symbols just give the run-away pointer more room to wander before he
> violates his memory space.
>
> So, my debugging method is to go through and wrap suspect function
> calls in printf()s to see where the segfault is. So far, while
> tedious, the crashing has been extremely consistent. I have tracked
> the segfault to this manually created backtrace (I'm calling the
> lowest function I've tracked it to cnotext 0 even though I'm not sure
> that is the exact function the segfault is occuring in. It's just as
> far as I've been able to track it):
>
> #0 ReaderMgr::createReader(), internal/ReaderMgr.cpp:463
> #1 DTDValidator::scanDocTypeDecl(),
> validators/DTD/DTDValidator2.cpp:1456
> #2 DTDValidator::scanDTD(), validators/DTD/DTDValidator.cpp:777
> #3 XMLScanner::scanProlog(), internal/XMLScanner.cpp:1890
> #4 XMLScanner::scanDocument(), internal/XMLScanner.cpp:285
> #5 XMLScanner::scanDocument(), internal/XMLScanner.cpp:241
> #6 SAXParser::parse(), parsers/SAXParser.cpp:368
> #7 our code calling the parser
>
> Note that the above line numbers are approximate due to the additions
> or printfs()s and #include <stdio.h>.
>
> The segfault in createReader is in this code:
>
> ,----[ ReaderMgr::createReader, lines 490 - 500 ]
> | // Call the entity resolver interface to get an input source
> | srcToFill = 0;
> | if (fEntityHandler)
> | {
> | printf("starting to resolveEntity\n");
> | srcToFill = fEntityHandler->resolveEntity
> | (
> | pubId
> | , expSysId.getRawBuffer()
> | );
> | printf("done\n");
> | }
> `----
>
> It never comes back from fEntityHandler->resolveEntity. My problem is
> that I can't find the definition of resolveEntity. The only actual
> definition I find is just { return 0; }.
>
> Can anyone who understands this code help me?
> --
> (__) Doug Alcorn (mailto:doug@lathi.net http://www.lathi.net)
> oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543
> |_/ If you're a capitalist and you have the best goods and they're
> free, you don't have to proselytize, you just have to wait.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
--
Kirk Wylie | mailto:kirk@radik.com | http://www.radik.com
Re: Segfault in ReaderMgr::createReader()
Posted by Miroslaw Dobrzanski-Neumann <mn...@mosaic-ag.com>.
On Thu, Feb 08, 2001 at 05:46:32PM -0500, Doug Alcorn wrote:
> The problem is fairly insidious because it only shows up when the app
> is compiled with debugging turned off. Also, no core file is being
> generated even though it segfaults. (I would love for someone to
> enlighten me on when a core file is produced and when it isn't. BTW,
> I tried running the process as root so that I was sure it would have
> write privileges in whatever directory it was in).
>
> Also note that the segfault doesn't turn up on every installation of
> Linux. My own rh7 box with the infamous gcc/g++ (2.96-54) and
> glibc/libstdc++ (2.1.92-14/2.96-54) doesn't crash regardless of
> whether I have debuggin symbols compiled in or not. However, our
> "build box" for non-rh7 binaries is a Debian potato with gcc/g++
> 2.95.2-13 and glibc 2.1.3-10. It consistently causes the crash, but
> only if you compile without debug symbols. My guess is that the debug
> symbols just give the run-away pointer more room to wander before he
> violates his memory space.
The most Linux installations have core dumping turned off. The reason for this
is clear. The most Linux users are not familiar with this concept and not
willing to have poluted their file system with core files.
1.
You can turn on this feature by setting limits in your shell:
sh, ksh, bash:
what limits are set: ulimit -a
fully enable core: ulimit -c unlimited
csh, tcsh:
what limits are set: limit
fully enable core: limit coredumpsize unlimited
2.
The gcc 2.95 has some problems with the -g option. You can achieve much better
results if you use -ggdb instead.
3.
For malloc debuging I successfully use the libefence. Preloading the library
you have nothing to do with your code. The library installs malloc handler and
causes crash (coredump) when it detect illegal memory access. Of corse you can
not detect all access voilations (no tool can this) but something is better
then nothing. for more information $ man efence
use in the shell:
$ env LD_PRELOAD=/usr/lib/libefence.so your_prog
you get a core if something wrong happens
use in gdb
(gdb) set environment PRELOAD=/usr/lib/libefence.so your_prog
(gdb) run
the debugger stops you code with SIGSEGV or SIGILL
Happy hacking
--
Miroslaw Dobrzanski-Neumann
MOSAIC SOFTWARE AG
Base Development and Research
Tel +49-2225-882-291
Fax +49-2225-882-201
E-mail: mne@mosaic-ag.com
Re: Segfault in ReaderMgr::createReader()
Posted by Dean Roddey <dr...@charmedquark.com>.
ResolveEntity() is memeber of a optionally installable callout object. If
your code has installed an entity handler, it will get called. Else, it
won't. The entity handler allows your code to see when each XML parseable
entity starts, ends, etc...
The fact that you are getting into that code means that either you have
installed an entity handler, or memory corruption has occured and
overwritten that file so that it looks like there is an entity handler. It
sounds like perhaps its the later, since it looks like perhaps you are
trapping becuase that is not a legal object pointer, so you end up looking
into a non-existent virtual function table, picking some random value that
happens to be there, and trying to call it.
--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com
"We're gonna need a bigger boat"
----- Original Message -----
From: "Doug Alcorn" <do...@lathi.net>
To: <xe...@xml.apache.org>
Sent: Thursday, February 08, 2001 2:46 PM
Subject: Segfault in ReaderMgr::createReader()
> It never comes back from fEntityHandler->resolveEntity. My problem is
> that I can't find the definition of resolveEntity. The only actual
> definition I find is just { return 0; }.
>
> Can anyone who understands this code help me?
> --
RE: Segfault in ReaderMgr::createReader()
Posted by "David E. Cleary" <da...@progress.com>.
> 2.95.2-13 and glibc 2.1.3-10. It consistently causes the crash, but
> only if you compile without debug symbols. My guess is that the debug
> symbols just give the run-away pointer more room to wander before he
> violates his memory space.
You sure it isn't an optimization bug you are running into? Try building a
non-debug version with optimization turned off. I had to do that myself on
Unixware.
David Cleary
Progress Software