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 Christian Kruse <ck...@wwwtech.de> on 2002/02/28 18:53:12 UTC
Xerces-C on FreeBSD 4.5
Hi,
I tried to compiler Xerces-C on my FreeBSD 4.5 system. It worked with ICU -ticu
and -tIconvFBSD, but when compiling the examples I get the following warnings:
/usr/lib/libc_r.so.4: WARNING! setkey(3) not present in the system!
/usr/lib/libc_r.so.4: warning: this program uses gets(), which is unsafe.
/usr/lib/libc_r.so.4: warning: mktemp() possibly used unsafely; consider using mkstemp()
/usr/lib/libc_r.so.4: WARNING! des_setkey(3) not present in the system!
/usr/lib/libc_r.so.4: WARNING! encrypt(3) not present in the system!
/usr/lib/libc_r.so.4: warning: tmpnam() possibly used unsafely; consider using mkstemp()
/usr/lib/libc_r.so.4: warning: this program uses f_prealloc(), which is not recommended.
/usr/lib/libc_r.so.4: WARNING! des_cipher(3) not present in the system!
/usr/lib/libc_r.so.4: warning: tempnam() possibly used unsafely; consider using mkstemp()
The binary works fine, but it core dumps after the 'return 0' at the end of
the samples. Can anybody help me with it? I don't know why it core dumps...
Greets,
CK
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Xerces-C on FreeBSD 4.5
Posted by Christian Kruse <ck...@wwwtech.de>.
Hoi,
On Thu, 28 Feb 2002 11:26:49 -0800 (PST)
John Utz <ut...@singingfish.com> wrote:
> and then look at the results, it will say which line in which function
> caused the core dump
I recompiled Xerces with ./runConfigure .... -d. The gdb-result was:
#0 0x282541c7 in XMLURL::parse (this=0x0, urlText=0x0) at XMLURL.cpp:852
852 while (*srcPtr)
(gdb) bt
#0 0x282541c7 in XMLURL::parse (this=0x0, urlText=0x0) at XMLURL.cpp:852
(gdb)
Does it help a little bit more?
Greets,
CK
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Xerces-C on FreeBSD 4.5
Posted by John Utz <ut...@singingfish.com>.
this is great work! i am happy to help as much as i can, esp since you
stepped thru it....
On Fri, 1 Mar 2002, Christian Kruse wrote:
> Hi,
>
> On Thu, 28 Feb 2002 12:40:49 -0800 (PST)
> John Utz <ut...@singingfish.com> wrote:
>
> > OK, we see here that the 'this' pointer and the urlText string are NULL! i
> > assume that the this is supposed to point to the XMLURL instance but i
> > dont really know.
>
> I think the error is in parsers/SAXParser.cpp:
> SAXParser::parse(const char *const systemId, const bool reuseGrammar):
>
> fScanner->scanDocument(systemId, reuseGrammar);
>
> This calls
>
> void XMLScanner::scanDocument( const XMLCh* const systemId
> , const bool reuseGrammar)
>
>
> you send const char *const systemId as a const XMLCh *const systemId.
> XMLCh is, when I understand rightfully, a wchar_t. In XMLScanner::scanDocument
> a XMLURL object is created with this const XMLCh* const, which is in deed
> a const char *const. The XMLURL-Constructor
>
> XMLURL::XMLURL(const XMLCh* const urlText)
>
> is called, which calls
>
> void XMLURL::setURL(const XMLCh* const urlText)
>
> This Method calls
>
> void XMLURL::parse(const XMLCh* const urlText)
>
> This Method makes a pointer 'XMLCh *srcPtr' to urlText and calls (in a
> loop):
>
> XMLPlatformUtils::fgTransService->isSpace(*srcPtr)
>
> This Method is defined in IconvFBSDTransService.cpp. It expects a XMLCh (which
> seems to be a wchar_t) and runs
>
> mbstowcs( (wchar_t*) &toCheck, buf, 1 );
>
> on *srcPtr, wich is really a const char. Could this be the error?
>
mbstowcs is MultiByteStringToWideCharString. it's a conversion routine.
is this *exactly* how it's coded?
mbstowcs( (wchar_t*) &toCheck, buf, 1 );
if so, fooie!
i *hate* it when folks dont check return values! it returns a size_t, and
viewing the man page indicates what it will return under what
circumstances
so, your suspicion is that it's unhappy *might* be easy to check by adding
a return value
i just read the man page for this function (on my linux box at work) and
it's full of fascinating facts.
my next suggestion would be to add a return val and see what the value is.
i'd also see if toCheck is NULL. and for that matter, that buf isnt NULL
either.
boy, i hope this helps. you've been working so hard at this!
> > > test.xml:
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <!DOCTYPE blah SYSTEM "test.dtd">
> > >
> > > <blah>
> > > <blub/>
> > > <blah>
> > > <blub/>
> > > </blah>
> > > </blah>
> > >
> > > test.dtd:
> > > <!ELEMENT blah ((blah|blub)+)>
> > > <!ELEMENT blub EMPTY>
> >
> > really nice trivial example! great for this sort of thing....
>
> Thanks.
>
> > i'd step all the way thru ( it's a pain in the ass, but...) and watch what
> > happens to the variables that either went NULL, or where never new'd in
> > the first place.... the place where they get initialized would be the most
> > interesting. you could probably grep around a bit and then just set a
> > breakpoint close to where they get set up and thus avoid much 's'-ing....
>
> So, I did it ;-) it's your turn ;-)
>
> Greets,
> CK
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Xerces-C on FreeBSD 4.5
Posted by Christian Kruse <ck...@wwwtech.de>.
Hi,
On Thu, 28 Feb 2002 12:40:49 -0800 (PST)
John Utz <ut...@singingfish.com> wrote:
> OK, we see here that the 'this' pointer and the urlText string are NULL! i
> assume that the this is supposed to point to the XMLURL instance but i
> dont really know.
I think the error is in parsers/SAXParser.cpp:
SAXParser::parse(const char *const systemId, const bool reuseGrammar):
fScanner->scanDocument(systemId, reuseGrammar);
This calls
void XMLScanner::scanDocument( const XMLCh* const systemId
, const bool reuseGrammar)
you send const char *const systemId as a const XMLCh *const systemId.
XMLCh is, when I understand rightfully, a wchar_t. In XMLScanner::scanDocument
a XMLURL object is created with this const XMLCh* const, which is in deed
a const char *const. The XMLURL-Constructor
XMLURL::XMLURL(const XMLCh* const urlText)
is called, which calls
void XMLURL::setURL(const XMLCh* const urlText)
This Method calls
void XMLURL::parse(const XMLCh* const urlText)
This Method makes a pointer 'XMLCh *srcPtr' to urlText and calls (in a
loop):
XMLPlatformUtils::fgTransService->isSpace(*srcPtr)
This Method is defined in IconvFBSDTransService.cpp. It expects a XMLCh (which
seems to be a wchar_t) and runs
mbstowcs( (wchar_t*) &toCheck, buf, 1 );
on *srcPtr, wich is really a const char. Could this be the error?
> > test.xml:
> > <?xml version="1.0" encoding="UTF-8"?>
> > <!DOCTYPE blah SYSTEM "test.dtd">
> >
> > <blah>
> > <blub/>
> > <blah>
> > <blub/>
> > </blah>
> > </blah>
> >
> > test.dtd:
> > <!ELEMENT blah ((blah|blub)+)>
> > <!ELEMENT blub EMPTY>
>
> really nice trivial example! great for this sort of thing....
Thanks.
> i'd step all the way thru ( it's a pain in the ass, but...) and watch what
> happens to the variables that either went NULL, or where never new'd in
> the first place.... the place where they get initialized would be the most
> interesting. you could probably grep around a bit and then just set a
> breakpoint close to where they get set up and thus avoid much 's'-ing....
So, I did it ;-) it's your turn ;-)
Greets,
CK
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Xerces-C on FreeBSD 4.5
Posted by John Utz <ut...@singingfish.com>.
ok both this mail and the previous mail show the same pathology.
it's instructional!
On Thu, 28 Feb 2002, Christian Kruse wrote:
> Hoi,
>
> On Thu, 28 Feb 2002 12:15:39 -0800 (PST)
> John Utz <ut...@singingfish.com> wrote:
>
> > Could i suggest a further test?
>
> Please :-)
>
> > try SEnumval or SAXPrint or DOMPrint and see what you get.
>
> #0 0x282541c7 in XMLURL::parse (this=0x0, urlText=0x0) at XMLURL.cpp:852
> 852 while (*srcPtr)
> (gdb) bt
> #0 0x282541c7 in XMLURL::parse (this=0x0, urlText=0x0) at XMLURL.cpp:852
> (gdb)
OK, we see here that the 'this' pointer and the urlText string are NULL! i
assume that the this is supposed to point to the XMLURL instance but i
dont really know.
> Output:
> <?xml version="1.0" encoding="LATIN1"?>
> Segmentation fault (core dumped)
>
> wich is really silly: my xml file is something different:
:-)
i am guessing that it's trying to make somthing out of nothing, and LATIN1
ends up being the default......
> test.xml:
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE blah SYSTEM "test.dtd">
>
> <blah>
> <blub/>
> <blah>
> <blub/>
> </blah>
> </blah>
>
> test.dtd:
> <!ELEMENT blah ((blah|blub)+)>
> <!ELEMENT blub EMPTY>
really nice trivial example! great for this sort of thing....
ok, the next step, where it me ( which it isnt, because i have a big high
visibility paper to write today that somebody else has to present, so i
*really* dont want to embarrass him! ),
i'd step all the way thru ( it's a pain in the ass, but...) and watch what
happens to the variables that either went NULL, or where never new'd in
the first place.... the place where they get initialized would be the most
interesting. you could probably grep around a bit and then just set a
breakpoint close to where they get set up and thus avoid much 's'-ing....
> Greets,
> CK
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Xerces-C on FreeBSD 4.5
Posted by Christian Kruse <ck...@wwwtech.de>.
Hoi,
On Thu, 28 Feb 2002 12:15:39 -0800 (PST)
John Utz <ut...@singingfish.com> wrote:
> Could i suggest a further test?
Please :-)
> try SEnumval or SAXPrint or DOMPrint and see what you get.
#0 0x282541c7 in XMLURL::parse (this=0x0, urlText=0x0) at XMLURL.cpp:852
852 while (*srcPtr)
(gdb) bt
#0 0x282541c7 in XMLURL::parse (this=0x0, urlText=0x0) at XMLURL.cpp:852
(gdb)
Output:
<?xml version="1.0" encoding="LATIN1"?>
Segmentation fault (core dumped)
wich is really silly: my xml file is something different:
test.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE blah SYSTEM "test.dtd">
<blah>
<blub/>
<blah>
<blub/>
</blah>
</blah>
test.dtd:
<!ELEMENT blah ((blah|blub)+)>
<!ELEMENT blub EMPTY>
Greets,
CK
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Xerces-C on FreeBSD 4.5
Posted by John Utz <ut...@singingfish.com>.
Could i suggest a further test?
try SEnumval or SAXPrint or DOMPrint and see what you get.
i am betting that you wont get any output that comes from the
actual elements....those where the ones that i was trying.
if it coredumps, and dumps in the same place, that would be
enlightening. if it dies elsewhere, that would be enlightening too...
i am currently *guessing* after looking at your backtrace that the XML
chars are sized incorrectly in some portion of the code, but not all of
it. thus, too big things are getting stuffed into too small holes and then
bad things are happening/
On Thu, 28 Feb 2002, Christian Kruse wrote:
> Hoi,
>
> On Thu, 28 Feb 2002 11:26:49 -0800 (PST)
> John Utz <ut...@singingfish.com> wrote:
>
> > well, if you got it to actually parse, u are ahead of me!
> >
> > On Thu, 28 Feb 2002, Christian Kruse wrote:
> >
> >> [...]
> > the warnings are not a problem, imho. they are a 'security warning'.
>
> I thougt so, too :-)
>
> > > The binary works fine, but it core dumps after the 'return 0' at the end of
> > > the samples. Can anybody help me with it? I don't know why it core dumps...
> >
> > well, as i said above, when i built xerces on my 4.4 box, it ran the
> > samples, but never seemd to parse the document.
>
> It parses the document. It's output is correct. I think a destructor of an
> object causes this core dump.
>
> > i would suggest checking that you built a debug version ( was compiled
> > with -g ) and then if it's a debug version, checking the core dump with
> > gdb.
>
> Done.
>
> > i think the command line would be:
> >
> > gdb xercesapp xercesapp.core
> >
> > then when it finishes loading, type:
> >
> > bt
> >
> > and then look at the results, it will say which line in which function
> > caused the core dump
>
> bash-2.05a$ gdb SAXCount SAXCount.core
> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-unknown-freebsd"...
> Core was generated by `SAXCount'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/local/xerces-c-src1_6_0/lib/libxerces-c1_6_0.so...
> done.
> Reading symbols from /usr/lib/libstdc++.so.3...done.
> Reading symbols from /usr/lib/libm.so.2...done.
> Reading symbols from /usr/lib/libc.so.4...done.
> Reading symbols from /usr/lib/libc_r.so.4...done.
> Reading symbols from /usr/libexec/ld-elf.so.1...done.
> #0 0x283db3b6 in xdr_u_int () from /usr/lib/libc.so.4
> (gdb) run test.xml
> Starting program: /usr/local/xerces-c-src1_6_0/samples/SAXCount/SAXCount test.xml
> test.xml: 4 ms (4 elems, 0 attrs, 10 spaces, 0 chars)
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x283db3b6 in xdr_u_int () from /usr/lib/libc.so.4
> (gdb) bt
> #0 0x283db3b6 in xdr_u_int () from /usr/lib/libc.so.4
> #1 0x283dbb1a in xdr_bytes () from /usr/lib/libc.so.4
> #2 0x283dbbec in xdr_netobj () from /usr/lib/libc.so.4
> #3 0x283f1416 in .cerror () from /usr/lib/libc.so.4
> #4 0x283f1317 in exit () from /usr/lib/libc.so.4
> #5 0x804912f in _start ()
> (gdb)
>
> Any ideas?
>
> Greets,
> CK
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Xerces-C on FreeBSD 4.5
Posted by Christian Kruse <ck...@wwwtech.de>.
Hoi,
On Thu, 28 Feb 2002 11:26:49 -0800 (PST)
John Utz <ut...@singingfish.com> wrote:
> well, if you got it to actually parse, u are ahead of me!
>
> On Thu, 28 Feb 2002, Christian Kruse wrote:
>
>> [...]
> the warnings are not a problem, imho. they are a 'security warning'.
I thougt so, too :-)
> > The binary works fine, but it core dumps after the 'return 0' at the end of
> > the samples. Can anybody help me with it? I don't know why it core dumps...
>
> well, as i said above, when i built xerces on my 4.4 box, it ran the
> samples, but never seemd to parse the document.
It parses the document. It's output is correct. I think a destructor of an
object causes this core dump.
> i would suggest checking that you built a debug version ( was compiled
> with -g ) and then if it's a debug version, checking the core dump with
> gdb.
Done.
> i think the command line would be:
>
> gdb xercesapp xercesapp.core
>
> then when it finishes loading, type:
>
> bt
>
> and then look at the results, it will say which line in which function
> caused the core dump
bash-2.05a$ gdb SAXCount SAXCount.core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
Core was generated by `SAXCount'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/xerces-c-src1_6_0/lib/libxerces-c1_6_0.so...
done.
Reading symbols from /usr/lib/libstdc++.so.3...done.
Reading symbols from /usr/lib/libm.so.2...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/lib/libc_r.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0 0x283db3b6 in xdr_u_int () from /usr/lib/libc.so.4
(gdb) run test.xml
Starting program: /usr/local/xerces-c-src1_6_0/samples/SAXCount/SAXCount test.xml
test.xml: 4 ms (4 elems, 0 attrs, 10 spaces, 0 chars)
Program received signal SIGSEGV, Segmentation fault.
0x283db3b6 in xdr_u_int () from /usr/lib/libc.so.4
(gdb) bt
#0 0x283db3b6 in xdr_u_int () from /usr/lib/libc.so.4
#1 0x283dbb1a in xdr_bytes () from /usr/lib/libc.so.4
#2 0x283dbbec in xdr_netobj () from /usr/lib/libc.so.4
#3 0x283f1416 in .cerror () from /usr/lib/libc.so.4
#4 0x283f1317 in exit () from /usr/lib/libc.so.4
#5 0x804912f in _start ()
(gdb)
Any ideas?
Greets,
CK
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Xerces-C on FreeBSD 4.5
Posted by John Utz <ut...@singingfish.com>.
well, if you got it to actually parse, u are ahead of me!
On Thu, 28 Feb 2002, Christian Kruse wrote:
> Hi,
>
> I tried to compiler Xerces-C on my FreeBSD 4.5 system. It worked with ICU -ticu
> and -tIconvFBSD, but when compiling the examples I get the following warnings:
>
> /usr/lib/libc_r.so.4: WARNING! setkey(3) not present in the system!
> /usr/lib/libc_r.so.4: warning: this program uses gets(), which is unsafe.
> /usr/lib/libc_r.so.4: warning: mktemp() possibly used unsafely; consider using mkstemp()
> /usr/lib/libc_r.so.4: WARNING! des_setkey(3) not present in the system!
> /usr/lib/libc_r.so.4: WARNING! encrypt(3) not present in the system!
> /usr/lib/libc_r.so.4: warning: tmpnam() possibly used unsafely; consider using mkstemp()
> /usr/lib/libc_r.so.4: warning: this program uses f_prealloc(), which is not recommended.
> /usr/lib/libc_r.so.4: WARNING! des_cipher(3) not present in the system!
> /usr/lib/libc_r.so.4: warning: tempnam() possibly used unsafely; consider using mkstemp()
the warnings are not a problem, imho. they are a 'security warning'.
other apps will inspire the linker to emit this warning too.
> The binary works fine, but it core dumps after the 'return 0' at the end of
> the samples. Can anybody help me with it? I don't know why it core dumps...
well, as i said above, when i built xerces on my 4.4 box, it ran the
samples, but never seemd to parse the document.
i would suggest checking that you built a debug version ( was compiled
with -g ) and then if it's a debug version, checking the core dump with
gdb.
i think the command line would be:
gdb xercesapp xercesapp.core
then when it finishes loading, type:
bt
and then look at the results, it will say which line in which function
caused the core dump
> Greets,
> CK
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org