From noreply@sourceforge.net Tue Sep 3 23:11:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 15:11:14 -0700 Subject: [Expat-bugs] [ expat-Bugs-604218 ] XML_ParserReset leaks Message-ID: Bugs item #604218, was opened at 2002-09-03 15:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=604218&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML_ParserReset leaks Initial Comment: XML_ParserReset() leaks memory like a screen door on a battleship. Not much of a point having it then, is there? This method would be really useful if it worked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=604218&group_id=10127 From noreply@sourceforge.net Tue Sep 3 23:34:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 15:34:15 -0700 Subject: [Expat-bugs] [ expat-Bugs-604218 ] XML_ParserReset leaks Message-ID: Bugs item #604218, was opened at 2002-09-03 18:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=604218&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML_ParserReset leaks Initial Comment: XML_ParserReset() leaks memory like a screen door on a battleship. Not much of a point having it then, is there? This method would be really useful if it worked. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-09-03 18:34 Message: Logged In: YES user_id=3066 What version of Expat are you using? If you are not using the latest version in CVS, then this has probably been fixed. The known leaks here are already fixed in CVS and will be part of Expat 1.95.5. If there is no response in a short period of time, this bug will be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=604218&group_id=10127 From noreply@sourceforge.net Wed Sep 4 00:08:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 16:08:18 -0700 Subject: [Expat-bugs] [ expat-Bugs-604218 ] XML_ParserReset leaks Message-ID: Bugs item #604218, was opened at 2002-09-03 18:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=604218&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML_ParserReset leaks Initial Comment: XML_ParserReset() leaks memory like a screen door on a battleship. Not much of a point having it then, is there? This method would be really useful if it worked. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-03 19:08 Message: Logged In: YES user_id=290026 To Fred's remarks I would like to add: If the current CVS still leaks, then please provide some details, so that we can reproduce the bug and fix it. That is, if you are interested in a fix. Actually, since this is all a volunteer effort, you might be able to contribute a fix yourself. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-09-03 18:34 Message: Logged In: YES user_id=3066 What version of Expat are you using? If you are not using the latest version in CVS, then this has probably been fixed. The known leaks here are already fixed in CVS and will be part of Expat 1.95.5. If there is no response in a short period of time, this bug will be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=604218&group_id=10127 From noreply@sourceforge.net Wed Sep 4 00:57:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 16:57:57 -0700 Subject: [Expat-bugs] [ expat-Bugs-594963 ] segmentation fault in function hash Message-ID: Bugs item #594963, was opened at 2002-08-14 04:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=594963&group_id=10127 Category: None Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: segmentation fault in function hash Initial Comment: expat 1.95.4 crashed in function lookup -> hash when used in my program. When used as parseXml -ivt **.T34 outx a memory error follows and a crash. This does not happend when line is removed or T34 is changed to T35 or an other item. GDB tells me it is a segmentation error. OS is HPUX-11. Compiler is GCC, Lang is ANSI-C. Can be circumvented by setting INIT_SIZE to 128 in xmlparse.c but no guaranties. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-09-03 19:57 Message: Logged In: YES user_id=3066 The sample code is a mess, and doesn't compile "out of the box." (What version of GCC did you use???) Please try to submit a cleaned-up version that doesn't require special compiler options or produce lots of spurious warnings. Is your box a 64-bit platform? ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-16 10:43 Message: Logged In: YES user_id=290026 Assigned to Fred. Hope he has time to give it a quick check. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-08-14 09:04 Message: Logged In: YES user_id=290026 Roel Dijkema was not able to upload the bug demo. I did that for him. Comment: It would be much appreciated if the demo could be reduced to the bare minimum that still shows the bug. Otherwise it may take too long to isolate the problem - since we all would like to use our limited volunteer time efficiently. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=594963&group_id=10127 From noreply@sourceforge.net Wed Sep 4 00:59:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 16:59:13 -0700 Subject: [Expat-bugs] [ expat-Bugs-591556 ] Solaris make error Message-ID: Bugs item #591556, was opened at 2002-08-06 10:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=591556&group_id=10127 >Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Greg Stein (gstein) Summary: Solaris make error Initial Comment: Receiving this error from the make process of 1.95.4 in both Solaris 2.8 and 2.5.1 using gcc and ccs/cc. make: Fatal error: Don't know how to make target 'xmlwf/xmlwf.c' Here is the Make file that is being generated from the ./configure process: ############################################### ################# # Process this file with top-level configure script to produce Makefile # # Copyright 2000 Clark Cooper # # This file is part of EXPAT. # # EXPAT is free software; you can redistribute it and/or modify it # under the terms of the License (based on the MIT/X license) contained # in the file COPYING that comes with this distribution. # # EXPAT IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, # EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF # MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. # IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY # CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, # TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE # SOFTWARE OR THE USE OR OTHER DEALINGS IN EXPAT. # SHELL = /bin/bash srcdir = . top_srcdir = . prefix = /usr/local exec_prefix = ${prefix} bindir = ${exec_prefix}/bin libdir = ${exec_prefix}/lib includedir = ${prefix}/include mandir = ${prefix}/man/man1 top_builddir = . INSTALL = conftools/install-sh -c INSTALL_PROGRAM = ${INSTALL} INSTALL_DATA = ${INSTALL} -m 644 mkinstalldirs = $(SHELL) $(top_srcdir)/conftools/mkinstalldirs MANFILE = $(srcdir)/doc/xmlwf.1 APIHEADER = $(srcdir)/lib/expat.h LIBRARY = libexpat.la default: buildlib xmlwf/xmlwf buildlib: $(LIBRARY) all: $(LIBRARY) xmlwf/xmlwf examples/elements examples/outline clean: cd lib && rm -f $(LIBRARY) *.o *.lo && rm - rf .libs _libs cd xmlwf && rm -f xmlwf *.o *.lo && rm - rf .libs _libs cd examples && rm -f elements outline *.o *.lo && rm -rf .libs _libs find . -name core | xargs rm -f distclean: clean rm -f expat_config.h config.status config.log config.cache libtool rm -f Makefile extraclean: distclean rm -f expat_config.h.in configure rm -f conftools/ltconfig conftools/ltmain.sh conftools/libtool.m4 check: tests/runtests tests/runtests install: xmlwf/xmlwf installlib $(mkinstalldirs) $(bindir) $(mandir) $(LIBTOOL) --mode=install $(INSTALL_PROGRAM) xmlwf/xmlwf $(bindir)/xmlwf $(INSTALL_DATA) $(MANFILE) $(mandir) installlib: $(LIBRARY) $(APIHEADER) $(mkinstalldirs) $(libdir) $(includedir) $(LIBTOOL) --mode=install $(INSTALL) $(LIBRARY) $(libdir)/$(LIBRARY) $(INSTALL_DATA) $(APIHEADER) $(includedir) uninstall: uninstalllib $(LIBTOOL) --mode=uninstall rm -f $(bindir)/xmlwf rm -f $(mandir)/xmlwf.1 uninstalllib: $(LIBTOOL) --mode=uninstall rm -f $(libdir)/ $(LIBRARY) rm -f $(includedir)/$(APIHEADER) # for VPATH builds (invoked by configure) mkdir-init: @for d in lib xmlwf examples tests ; do \ (mkdir $$d 2> /dev/null || test 1) ; \ done CC = gcc LIBTOOL = $(SHELL) $(top_builddir)/libtool INCLUDES = -I$(srcdir)/lib -I. LDFLAGS = CPPFLAGS = CFLAGS = -g -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions VSNFLAG = -version-info 3:0:3 ### autoconf this? LTFLAGS = --silent COMPILE = $(CC) $(CFLAGS) $(DEFS) $(CPPFLAGS) $(INCLUDES) LTCOMPILE = $(LIBTOOL) $(LTFLAGS) -- mode=compile $(COMPILE) LINK_LIB = $(LIBTOOL) $(LTFLAGS) --mode=link $(COMPILE) -no-undefined $(VSNFLAG) -rpath $(libdir) $(LDFLAGS) -o $@ LINK_EXE = $(LIBTOOL) $(LTFLAGS) --mode=link $(COMPILE) $(LDFLAGS) -o $@ LIB_OBJS = lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo $(LIBRARY): $(LIB_OBJS) $(LINK_LIB) $(LIB_OBJS) lib/xmlparse.lo: lib/xmlparse.c lib/expat.h lib/xmlrole.h lib/xmltok.h \ $(top_builddir)/expat_config.h lib/xmlrole.lo: lib/xmlrole.c lib/ascii.h lib/xmlrole.h \ $(top_builddir)/expat_config.h lib/xmltok.lo: lib/xmltok.c lib/xmltok_impl.c lib/xmltok_ns.c \ lib/ascii.h lib/asciitab.h lib/iasciitab.h lib/latin1tab.h \ lib/nametab.h lib/utf8tab.h lib/xmltok.h lib/xmltok_impl.h \ $(top_builddir)/expat_config.h XMLWF_OBJS = xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/unixfilemap.o xmlwf/xmlwf.o: xmlwf/xmlwf.c xmlwf/xmlfile.o: xmlwf/xmlfile.c xmlwf/codepage.o: xmlwf/codepage.c xmlwf/unixfilemap.o: xmlwf/unixfilemap.c xmlwf/xmlwf: $(XMLWF_OBJS) $(LIBRARY) $(LINK_EXE) $(XMLWF_OBJS) $(LIBRARY) examples/elements.o: examples/elements.c examples/elements: examples/elements.o $(LIBRARY) $(LINK_EXE) $< $(LIBRARY) examples/outline.o: examples/outline.c examples/outline: examples/outline.o $(LIBRARY) $(LINK_EXE) $< $(LIBRARY) tests/chardata.o: tests/chardata.c tests/chardata.h tests/runtests.o: tests/runtests.c tests/chardata.h tests/runtests: tests/runtests.o tests/chardata.o $(LIBRARY) $(LINK_EXE) $^ -lcheck tests/xmltest.zip: cd tests && wget ftp://ftp.jclark.com/pub/xml/xmltest.zip tests/xmltest: tests/xmltest.zip cd tests && unzip -q xmltest.zip run-xmltest: xmlwf/xmlwf tests/xmltest tests/xmltest.sh .SUFFIXES: .c .lo .o .c.o: $(COMPILE) -o $@ -c $< .c.lo: $(LTCOMPILE) -o $@ -c $< .PHONY: buildlib all \ clean distclean extraclean maintainer-clean \ dist distdir \ install uninstall Any help would be greatly appreciated. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-31 09:26 Message: Logged In: NO Are you using Sun's make? This isn't a wise thing when you are working with autoconf-generated stuff -- and you are! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=591556&group_id=10127 From noreply@sourceforge.net Mon Sep 9 23:33:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 15:33:21 -0700 Subject: [Expat-bugs] [ expat-Bugs-591556 ] Solaris make error Message-ID: Bugs item #591556, was opened at 2002-08-06 07:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=591556&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Solaris make error Initial Comment: Receiving this error from the make process of 1.95.4 in both Solaris 2.8 and 2.5.1 using gcc and ccs/cc. make: Fatal error: Don't know how to make target 'xmlwf/xmlwf.c' Here is the Make file that is being generated from the ./configure process: ############################################### ################# # Process this file with top-level configure script to produce Makefile # # Copyright 2000 Clark Cooper # # This file is part of EXPAT. # # EXPAT is free software; you can redistribute it and/or modify it # under the terms of the License (based on the MIT/X license) contained # in the file COPYING that comes with this distribution. # # EXPAT IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, # EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF # MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. # IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY # CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, # TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE # SOFTWARE OR THE USE OR OTHER DEALINGS IN EXPAT. # SHELL = /bin/bash srcdir = . top_srcdir = . prefix = /usr/local exec_prefix = ${prefix} bindir = ${exec_prefix}/bin libdir = ${exec_prefix}/lib includedir = ${prefix}/include mandir = ${prefix}/man/man1 top_builddir = . INSTALL = conftools/install-sh -c INSTALL_PROGRAM = ${INSTALL} INSTALL_DATA = ${INSTALL} -m 644 mkinstalldirs = $(SHELL) $(top_srcdir)/conftools/mkinstalldirs MANFILE = $(srcdir)/doc/xmlwf.1 APIHEADER = $(srcdir)/lib/expat.h LIBRARY = libexpat.la default: buildlib xmlwf/xmlwf buildlib: $(LIBRARY) all: $(LIBRARY) xmlwf/xmlwf examples/elements examples/outline clean: cd lib && rm -f $(LIBRARY) *.o *.lo && rm - rf .libs _libs cd xmlwf && rm -f xmlwf *.o *.lo && rm - rf .libs _libs cd examples && rm -f elements outline *.o *.lo && rm -rf .libs _libs find . -name core | xargs rm -f distclean: clean rm -f expat_config.h config.status config.log config.cache libtool rm -f Makefile extraclean: distclean rm -f expat_config.h.in configure rm -f conftools/ltconfig conftools/ltmain.sh conftools/libtool.m4 check: tests/runtests tests/runtests install: xmlwf/xmlwf installlib $(mkinstalldirs) $(bindir) $(mandir) $(LIBTOOL) --mode=install $(INSTALL_PROGRAM) xmlwf/xmlwf $(bindir)/xmlwf $(INSTALL_DATA) $(MANFILE) $(mandir) installlib: $(LIBRARY) $(APIHEADER) $(mkinstalldirs) $(libdir) $(includedir) $(LIBTOOL) --mode=install $(INSTALL) $(LIBRARY) $(libdir)/$(LIBRARY) $(INSTALL_DATA) $(APIHEADER) $(includedir) uninstall: uninstalllib $(LIBTOOL) --mode=uninstall rm -f $(bindir)/xmlwf rm -f $(mandir)/xmlwf.1 uninstalllib: $(LIBTOOL) --mode=uninstall rm -f $(libdir)/ $(LIBRARY) rm -f $(includedir)/$(APIHEADER) # for VPATH builds (invoked by configure) mkdir-init: @for d in lib xmlwf examples tests ; do \ (mkdir $$d 2> /dev/null || test 1) ; \ done CC = gcc LIBTOOL = $(SHELL) $(top_builddir)/libtool INCLUDES = -I$(srcdir)/lib -I. LDFLAGS = CPPFLAGS = CFLAGS = -g -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions VSNFLAG = -version-info 3:0:3 ### autoconf this? LTFLAGS = --silent COMPILE = $(CC) $(CFLAGS) $(DEFS) $(CPPFLAGS) $(INCLUDES) LTCOMPILE = $(LIBTOOL) $(LTFLAGS) -- mode=compile $(COMPILE) LINK_LIB = $(LIBTOOL) $(LTFLAGS) --mode=link $(COMPILE) -no-undefined $(VSNFLAG) -rpath $(libdir) $(LDFLAGS) -o $@ LINK_EXE = $(LIBTOOL) $(LTFLAGS) --mode=link $(COMPILE) $(LDFLAGS) -o $@ LIB_OBJS = lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo $(LIBRARY): $(LIB_OBJS) $(LINK_LIB) $(LIB_OBJS) lib/xmlparse.lo: lib/xmlparse.c lib/expat.h lib/xmlrole.h lib/xmltok.h \ $(top_builddir)/expat_config.h lib/xmlrole.lo: lib/xmlrole.c lib/ascii.h lib/xmlrole.h \ $(top_builddir)/expat_config.h lib/xmltok.lo: lib/xmltok.c lib/xmltok_impl.c lib/xmltok_ns.c \ lib/ascii.h lib/asciitab.h lib/iasciitab.h lib/latin1tab.h \ lib/nametab.h lib/utf8tab.h lib/xmltok.h lib/xmltok_impl.h \ $(top_builddir)/expat_config.h XMLWF_OBJS = xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/unixfilemap.o xmlwf/xmlwf.o: xmlwf/xmlwf.c xmlwf/xmlfile.o: xmlwf/xmlfile.c xmlwf/codepage.o: xmlwf/codepage.c xmlwf/unixfilemap.o: xmlwf/unixfilemap.c xmlwf/xmlwf: $(XMLWF_OBJS) $(LIBRARY) $(LINK_EXE) $(XMLWF_OBJS) $(LIBRARY) examples/elements.o: examples/elements.c examples/elements: examples/elements.o $(LIBRARY) $(LINK_EXE) $< $(LIBRARY) examples/outline.o: examples/outline.c examples/outline: examples/outline.o $(LIBRARY) $(LINK_EXE) $< $(LIBRARY) tests/chardata.o: tests/chardata.c tests/chardata.h tests/runtests.o: tests/runtests.c tests/chardata.h tests/runtests: tests/runtests.o tests/chardata.o $(LIBRARY) $(LINK_EXE) $^ -lcheck tests/xmltest.zip: cd tests && wget ftp://ftp.jclark.com/pub/xml/xmltest.zip tests/xmltest: tests/xmltest.zip cd tests && unzip -q xmltest.zip run-xmltest: xmlwf/xmlwf tests/xmltest tests/xmltest.sh .SUFFIXES: .c .lo .o .c.o: $(COMPILE) -o $@ -c $< .c.lo: $(LTCOMPILE) -o $@ -c $< .PHONY: buildlib all \ clean distclean extraclean maintainer-clean \ dist distdir \ install uninstall Any help would be greatly appreciated. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-09 15:33 Message: Logged In: NO Hello, Sir, I run into a make problem on Solaris 8. system info:[24] zhangy@zhangy: uname -a SunOS zhangy 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-5_10 I download the perl module XML::Parser (version 2.31, released on from www.cpan.org. Before I install above module, I install expat first. I download expat module from http://sourceforge.net/project/expat/ and put the file under directory /home/zhangy/perl/module/ then unzip the file: gzip -d .gz expat-1.95.5.tar then tar -xvf expat-1.95.5.tar then under directory /home/zhangy/perl/module/expat-1.95.5/ do the following: 1) type from prompt: ./configure --prefix=/home/zhangy/perl/perlxml/ CC=/net/bandsaw2/tools/on81-tools/SUNWspro/SC6.1-new/bin/cc 2) type from prompt make 3) type from prompt make install so far so good. Then I begin to install XML::Parser under directory: /home/zhangy/perl/module/XML-Parser-2.31/ from prompt type: perl Makefile.PL PREFIX=/home/zhangy/perl INSTALLDIRS=module EXPATLIBPATH=/home/zhangy/perl/perlxml/lib EXPATINCPATH=/home/zhangy/perl/perlxml/include/ It shows: Writing Makefile for XML::Parser::Expat Writing Makefile for XML::Parser SO FAR SO GOOD. Then still under dir /home/zhangy/perl/module/XML-Parser-2.31/ from prompt type: make it shows: ******************************************************************** [51] zhangy@zhangy: make cc -c -I/home/zhangy/perl/perlxml/include/ -xO3 -xdepend -DVERSION=\2.31\ -DXS_VERSION=\2.31\ -KPIC -I/usr/perl5/5.00503/sun4-solaris/CORE Expat.c /usr/ucb/cc: language optional software package not installed *** Error code 1 make: Fatal error: Command failed for target `Expat.o' Current working directory /home/zhangy/perl/module/XML-Parser-2.31/Expat *** Error code 1 make: Fatal error: Command failed for target `subdirs' ******************************************************************* So what is wrong for the installation? Where do I get the "language optional software package" that is not installed? Thanks for help. Charlie ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-31 06:26 Message: Logged In: NO Are you using Sun's make? This isn't a wise thing when you are working with autoconf-generated stuff -- and you are! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=591556&group_id=10127 From noreply@sourceforge.net Tue Sep 10 16:22:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 08:22:03 -0700 Subject: [Expat-bugs] [ expat-Bugs-591556 ] Solaris make error Message-ID: Bugs item #591556, was opened at 2002-08-06 07:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=591556&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: Solaris make error Initial Comment: Receiving this error from the make process of 1.95.4 in both Solaris 2.8 and 2.5.1 using gcc and ccs/cc. make: Fatal error: Don't know how to make target 'xmlwf/xmlwf.c' Here is the Make file that is being generated from the ./configure process: ############################################### ################# # Process this file with top-level configure script to produce Makefile # # Copyright 2000 Clark Cooper # # This file is part of EXPAT. # # EXPAT is free software; you can redistribute it and/or modify it # under the terms of the License (based on the MIT/X license) contained # in the file COPYING that comes with this distribution. # # EXPAT IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, # EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF # MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. # IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY # CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, # TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE # SOFTWARE OR THE USE OR OTHER DEALINGS IN EXPAT. # SHELL = /bin/bash srcdir = . top_srcdir = . prefix = /usr/local exec_prefix = ${prefix} bindir = ${exec_prefix}/bin libdir = ${exec_prefix}/lib includedir = ${prefix}/include mandir = ${prefix}/man/man1 top_builddir = . INSTALL = conftools/install-sh -c INSTALL_PROGRAM = ${INSTALL} INSTALL_DATA = ${INSTALL} -m 644 mkinstalldirs = $(SHELL) $(top_srcdir)/conftools/mkinstalldirs MANFILE = $(srcdir)/doc/xmlwf.1 APIHEADER = $(srcdir)/lib/expat.h LIBRARY = libexpat.la default: buildlib xmlwf/xmlwf buildlib: $(LIBRARY) all: $(LIBRARY) xmlwf/xmlwf examples/elements examples/outline clean: cd lib && rm -f $(LIBRARY) *.o *.lo && rm - rf .libs _libs cd xmlwf && rm -f xmlwf *.o *.lo && rm - rf .libs _libs cd examples && rm -f elements outline *.o *.lo && rm -rf .libs _libs find . -name core | xargs rm -f distclean: clean rm -f expat_config.h config.status config.log config.cache libtool rm -f Makefile extraclean: distclean rm -f expat_config.h.in configure rm -f conftools/ltconfig conftools/ltmain.sh conftools/libtool.m4 check: tests/runtests tests/runtests install: xmlwf/xmlwf installlib $(mkinstalldirs) $(bindir) $(mandir) $(LIBTOOL) --mode=install $(INSTALL_PROGRAM) xmlwf/xmlwf $(bindir)/xmlwf $(INSTALL_DATA) $(MANFILE) $(mandir) installlib: $(LIBRARY) $(APIHEADER) $(mkinstalldirs) $(libdir) $(includedir) $(LIBTOOL) --mode=install $(INSTALL) $(LIBRARY) $(libdir)/$(LIBRARY) $(INSTALL_DATA) $(APIHEADER) $(includedir) uninstall: uninstalllib $(LIBTOOL) --mode=uninstall rm -f $(bindir)/xmlwf rm -f $(mandir)/xmlwf.1 uninstalllib: $(LIBTOOL) --mode=uninstall rm -f $(libdir)/ $(LIBRARY) rm -f $(includedir)/$(APIHEADER) # for VPATH builds (invoked by configure) mkdir-init: @for d in lib xmlwf examples tests ; do \ (mkdir $$d 2> /dev/null || test 1) ; \ done CC = gcc LIBTOOL = $(SHELL) $(top_builddir)/libtool INCLUDES = -I$(srcdir)/lib -I. LDFLAGS = CPPFLAGS = CFLAGS = -g -O2 -Wall -Wmissing-prototypes -Wstrict- prototypes -fexceptions VSNFLAG = -version-info 3:0:3 ### autoconf this? LTFLAGS = --silent COMPILE = $(CC) $(CFLAGS) $(DEFS) $(CPPFLAGS) $(INCLUDES) LTCOMPILE = $(LIBTOOL) $(LTFLAGS) -- mode=compile $(COMPILE) LINK_LIB = $(LIBTOOL) $(LTFLAGS) --mode=link $(COMPILE) -no-undefined $(VSNFLAG) -rpath $(libdir) $(LDFLAGS) -o $@ LINK_EXE = $(LIBTOOL) $(LTFLAGS) --mode=link $(COMPILE) $(LDFLAGS) -o $@ LIB_OBJS = lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo $(LIBRARY): $(LIB_OBJS) $(LINK_LIB) $(LIB_OBJS) lib/xmlparse.lo: lib/xmlparse.c lib/expat.h lib/xmlrole.h lib/xmltok.h \ $(top_builddir)/expat_config.h lib/xmlrole.lo: lib/xmlrole.c lib/ascii.h lib/xmlrole.h \ $(top_builddir)/expat_config.h lib/xmltok.lo: lib/xmltok.c lib/xmltok_impl.c lib/xmltok_ns.c \ lib/ascii.h lib/asciitab.h lib/iasciitab.h lib/latin1tab.h \ lib/nametab.h lib/utf8tab.h lib/xmltok.h lib/xmltok_impl.h \ $(top_builddir)/expat_config.h XMLWF_OBJS = xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/unixfilemap.o xmlwf/xmlwf.o: xmlwf/xmlwf.c xmlwf/xmlfile.o: xmlwf/xmlfile.c xmlwf/codepage.o: xmlwf/codepage.c xmlwf/unixfilemap.o: xmlwf/unixfilemap.c xmlwf/xmlwf: $(XMLWF_OBJS) $(LIBRARY) $(LINK_EXE) $(XMLWF_OBJS) $(LIBRARY) examples/elements.o: examples/elements.c examples/elements: examples/elements.o $(LIBRARY) $(LINK_EXE) $< $(LIBRARY) examples/outline.o: examples/outline.c examples/outline: examples/outline.o $(LIBRARY) $(LINK_EXE) $< $(LIBRARY) tests/chardata.o: tests/chardata.c tests/chardata.h tests/runtests.o: tests/runtests.c tests/chardata.h tests/runtests: tests/runtests.o tests/chardata.o $(LIBRARY) $(LINK_EXE) $^ -lcheck tests/xmltest.zip: cd tests && wget ftp://ftp.jclark.com/pub/xml/xmltest.zip tests/xmltest: tests/xmltest.zip cd tests && unzip -q xmltest.zip run-xmltest: xmlwf/xmlwf tests/xmltest tests/xmltest.sh .SUFFIXES: .c .lo .o .c.o: $(COMPILE) -o $@ -c $< .c.lo: $(LTCOMPILE) -o $@ -c $< .PHONY: buildlib all \ clean distclean extraclean maintainer-clean \ dist distdir \ install uninstall Any help would be greatly appreciated. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-10 08:22 Message: Logged In: NO An answer to zhangy@zhangy, although this is not a right place for one. Sorry... You seem to be using GCC on Solaris. /usr/ucb/cc is just a wrapper script made by Sun which tries to find Sun's C compiler. I know almost nothing about Perl and its libraries (and I think that you know almost nothing about Solaris, he-he ;), but I suggest you to make Perl configuration script use 'gcc' instead of 'cc'. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-09 15:33 Message: Logged In: NO Hello, Sir, I run into a make problem on Solaris 8. system info:[24] zhangy@zhangy: uname -a SunOS zhangy 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-5_10 I download the perl module XML::Parser (version 2.31, released on from www.cpan.org. Before I install above module, I install expat first. I download expat module from http://sourceforge.net/project/expat/ and put the file under directory /home/zhangy/perl/module/ then unzip the file: gzip -d .gz expat-1.95.5.tar then tar -xvf expat-1.95.5.tar then under directory /home/zhangy/perl/module/expat-1.95.5/ do the following: 1) type from prompt: ./configure --prefix=/home/zhangy/perl/perlxml/ CC=/net/bandsaw2/tools/on81-tools/SUNWspro/SC6.1-new/bin/cc 2) type from prompt make 3) type from prompt make install so far so good. Then I begin to install XML::Parser under directory: /home/zhangy/perl/module/XML-Parser-2.31/ from prompt type: perl Makefile.PL PREFIX=/home/zhangy/perl INSTALLDIRS=module EXPATLIBPATH=/home/zhangy/perl/perlxml/lib EXPATINCPATH=/home/zhangy/perl/perlxml/include/ It shows: Writing Makefile for XML::Parser::Expat Writing Makefile for XML::Parser SO FAR SO GOOD. Then still under dir /home/zhangy/perl/module/XML-Parser-2.31/ from prompt type: make it shows: ******************************************************************** [51] zhangy@zhangy: make cc -c -I/home/zhangy/perl/perlxml/include/ -xO3 -xdepend -DVERSION=\2.31\ -DXS_VERSION=\2.31\ -KPIC -I/usr/perl5/5.00503/sun4-solaris/CORE Expat.c /usr/ucb/cc: language optional software package not installed *** Error code 1 make: Fatal error: Command failed for target `Expat.o' Current working directory /home/zhangy/perl/module/XML-Parser-2.31/Expat *** Error code 1 make: Fatal error: Command failed for target `subdirs' ******************************************************************* So what is wrong for the installation? Where do I get the "language optional software package" that is not installed? Thanks for help. Charlie ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-31 06:26 Message: Logged In: NO Are you using Sun's make? This isn't a wise thing when you are working with autoconf-generated stuff -- and you are! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=591556&group_id=10127 From noreply@sourceforge.net Wed Sep 11 09:25:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 01:25:09 -0700 Subject: [Expat-bugs] [ expat-Bugs-607702 ] expat v1.9.5+ Message-ID: Bugs item #607702, was opened at 2002-09-11 08:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=607702&group_id=10127 Category: www.libexpat.org Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Shamim Islam (kellin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat v1.9.5+ Initial Comment: PHP 4.2.2 - direct relay into expat 1.9.5 Apache 1.3.x Windows NT Linux-Mandrake Processing instructions according to the W3C workgroup do not form part of the character stream, but are supposed to be passed directly to the application. As such, they should be allowed to appear anywhere. xml and Xml as targets are reserved. The targets can make use of a Notation in the dtd to clarify the application to receive the processing instruction. Expat as constructed does not allow for processing instructions to appear anywhere arbitrarily but requires that they appear outside tags. However, the W3C mandate clearly indicates that is a valid construct. In attempting to make use of this construct, expat repeatedly stopped with an invalid response. Also, it was not clear whether the processing instruction was expected to return a value that would instead be substituted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=607702&group_id=10127 From noreply@sourceforge.net Wed Sep 11 09:26:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 01:26:25 -0700 Subject: [Expat-bugs] [ expat-Bugs-607704 ] expat v1.9.5+ error on Message-ID: Bugs item #607704, was opened at 2002-09-11 08:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=607704&group_id=10127 Category: www.libexpat.org Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Shamim Islam (kellin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat v1.9.5+ error on Initial Comment: PHP 4.2.2 - direct relay into expat 1.9.5 Apache 1.3.x Windows NT Linux-Mandrake Processing instructions according to the W3C workgroup do not form part of the character stream, but are supposed to be passed directly to the application. As such, they should be allowed to appear anywhere. xml and Xml as targets are reserved. The targets can make use of a Notation in the dtd to clarify the application to receive the processing instruction. Expat as constructed does not allow for processing instructions to appear anywhere arbitrarily but requires that they appear outside tags. However, the W3C mandate clearly indicates that is a valid construct. In attempting to make use of this construct, expat repeatedly stopped with an invalid response. Also, it was not clear whether the processing instruction was expected to return a value that would instead be substituted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=607704&group_id=10127 From noreply@sourceforge.net Wed Sep 11 09:27:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 01:27:18 -0700 Subject: [Expat-bugs] [ expat-Bugs-607704 ] expat v1.9.5+ error on Message-ID: Bugs item #607704, was opened at 2002-09-11 08:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=607704&group_id=10127 Category: www.libexpat.org >Group: Third-party Bug Status: Open Resolution: None >Priority: 9 Submitted By: Shamim Islam (kellin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat v1.9.5+ error on Initial Comment: PHP 4.2.2 - direct relay into expat 1.9.5 Apache 1.3.x Windows NT Linux-Mandrake Processing instructions according to the W3C workgroup do not form part of the character stream, but are supposed to be passed directly to the application. As such, they should be allowed to appear anywhere. xml and Xml as targets are reserved. The targets can make use of a Notation in the dtd to clarify the application to receive the processing instruction. Expat as constructed does not allow for processing instructions to appear anywhere arbitrarily but requires that they appear outside tags. However, the W3C mandate clearly indicates that is a valid construct. In attempting to make use of this construct, expat repeatedly stopped with an invalid response. Also, it was not clear whether the processing instruction was expected to return a value that would instead be substituted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=607704&group_id=10127 From noreply@sourceforge.net Wed Sep 11 15:06:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 07:06:03 -0700 Subject: [Expat-bugs] [ expat-Bugs-607704 ] expat v1.9.5+ error on Message-ID: Bugs item #607704, was opened at 2002-09-11 04:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=607704&group_id=10127 Category: www.libexpat.org Group: Third-party Bug >Status: Closed >Resolution: Duplicate Priority: 9 Submitted By: Shamim Islam (kellin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat v1.9.5+ error on Initial Comment: PHP 4.2.2 - direct relay into expat 1.9.5 Apache 1.3.x Windows NT Linux-Mandrake Processing instructions according to the W3C workgroup do not form part of the character stream, but are supposed to be passed directly to the application. As such, they should be allowed to appear anywhere. xml and Xml as targets are reserved. The targets can make use of a Notation in the dtd to clarify the application to receive the processing instruction. Expat as constructed does not allow for processing instructions to appear anywhere arbitrarily but requires that they appear outside tags. However, the W3C mandate clearly indicates that is a valid construct. In attempting to make use of this construct, expat repeatedly stopped with an invalid response. Also, it was not clear whether the processing instruction was expected to return a value that would instead be substituted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=607704&group_id=10127 From noreply@sourceforge.net Wed Sep 11 15:07:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 07:07:18 -0700 Subject: [Expat-bugs] [ expat-Bugs-607702 ] expat v1.9.5+ error on Message-ID: Bugs item #607702, was opened at 2002-09-11 04:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=607702&group_id=10127 >Category: None >Group: None Status: Open >Resolution: Rejected Priority: 5 Submitted By: Shamim Islam (kellin) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: expat v1.9.5+ error on Initial Comment: PHP 4.2.2 - direct relay into expat 1.9.5 Apache 1.3.x Windows NT Linux-Mandrake Processing instructions according to the W3C workgroup do not form part of the character stream, but are supposed to be passed directly to the application. As such, they should be allowed to appear anywhere. xml and Xml as targets are reserved. The targets can make use of a Notation in the dtd to clarify the application to receive the processing instruction. Expat as constructed does not allow for processing instructions to appear anywhere arbitrarily but requires that they appear outside tags. However, the W3C mandate clearly indicates that is a valid construct. In attempting to make use of this construct, expat repeatedly stopped with an invalid response. Also, it was not clear whether the processing instruction was expected to return a value that would instead be substituted. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-11 10:02 Message: Logged In: YES user_id=290026 The start tag is defined as: [40] STag ::= '<' Name (S Attribute)* S? '>' [41] Attribute ::= Name Eq AttValue and AttValue is defined as: [10] AttValue ::= '"' ([^<&"] | Reference)* '"' | "'" ([^<&'] | Reference)* "'" with Reference being a character or entity reference. This does not allow for processing instructions in the attribute value. The Expat behaviour looks correct to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=607702&group_id=10127 From noreply@sourceforge.net Wed Sep 11 15:02:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 07:02:15 -0700 Subject: [Expat-bugs] [ expat-Bugs-607702 ] expat v1.9.5+ Message-ID: Bugs item #607702, was opened at 2002-09-11 04:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=607702&group_id=10127 Category: www.libexpat.org Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Shamim Islam (kellin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat v1.9.5+ Initial Comment: PHP 4.2.2 - direct relay into expat 1.9.5 Apache 1.3.x Windows NT Linux-Mandrake Processing instructions according to the W3C workgroup do not form part of the character stream, but are supposed to be passed directly to the application. As such, they should be allowed to appear anywhere. xml and Xml as targets are reserved. The targets can make use of a Notation in the dtd to clarify the application to receive the processing instruction. Expat as constructed does not allow for processing instructions to appear anywhere arbitrarily but requires that they appear outside tags. However, the W3C mandate clearly indicates that is a valid construct. In attempting to make use of this construct, expat repeatedly stopped with an invalid response. Also, it was not clear whether the processing instruction was expected to return a value that would instead be substituted. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-11 10:02 Message: Logged In: YES user_id=290026 The start tag is defined as: [40] STag ::= '<' Name (S Attribute)* S? '>' [41] Attribute ::= Name Eq AttValue and AttValue is defined as: [10] AttValue ::= '"' ([^<&"] | Reference)* '"' | "'" ([^<&'] | Reference)* "'" with Reference being a character or entity reference. This does not allow for processing instructions in the attribute value. The Expat behaviour looks correct to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=607702&group_id=10127 From noreply@sourceforge.net Wed Sep 11 15:08:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 07:08:50 -0700 Subject: [Expat-bugs] [ expat-Bugs-604218 ] XML_ParserReset leaks Message-ID: Bugs item #604218, was opened at 2002-09-03 18:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=604218&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XML_ParserReset leaks Initial Comment: XML_ParserReset() leaks memory like a screen door on a battleship. Not much of a point having it then, is there? This method would be really useful if it worked. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-11 10:08 Message: Logged In: YES user_id=290026 No response - seems fixed in release 1.95.5. Therefore closed. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-03 19:08 Message: Logged In: YES user_id=290026 To Fred's remarks I would like to add: If the current CVS still leaks, then please provide some details, so that we can reproduce the bug and fix it. That is, if you are interested in a fix. Actually, since this is all a volunteer effort, you might be able to contribute a fix yourself. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-09-03 18:34 Message: Logged In: YES user_id=3066 What version of Expat are you using? If you are not using the latest version in CVS, then this has probably been fixed. The known leaks here are already fixed in CVS and will be part of Expat 1.95.5. If there is no response in a short period of time, this bug will be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=604218&group_id=10127 From noreply@sourceforge.net Thu Sep 12 18:05:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 10:05:09 -0700 Subject: [Expat-bugs] [ expat-Bugs-608476 ] libexpat crashed Message-ID: Bugs item #608476, was opened at 2002-09-12 10:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=608476&group_id=10127 Category: www.libexpat.org Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: libexpat crashed Initial Comment: An exception is caused when the message to be parsed is not wellformed in such a specific way: the "<" for the root element is missing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=608476&group_id=10127 From noreply@sourceforge.net Thu Sep 12 18:12:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 10:12:37 -0700 Subject: [Expat-bugs] [ expat-Bugs-608484 ] redundant namespace declaration Message-ID: Bugs item #608484, was opened at 2002-09-12 10:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=608484&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: redundant namespace declaration Initial Comment: A redundant namespace declaration in a single element, such as: cause the parser to crash in any case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=608484&group_id=10127 From noreply@sourceforge.net Thu Sep 12 18:13:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 10:13:01 -0700 Subject: [Expat-bugs] [ expat-Bugs-608476 ] libexpat crashed Message-ID: Bugs item #608476, was opened at 2002-09-12 13:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=608476&group_id=10127 Category: www.libexpat.org Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: libexpat crashed Initial Comment: An exception is caused when the message to be parsed is not wellformed in such a specific way: the "<" for the root element is missing. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-12 13:13 Message: Logged In: YES user_id=290026 What do you mean? Expat is supposed to return an error in such a case. Or do you mean a memory access violation? Btw, Expat itself is written in C and therefore does not throw exceptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=608476&group_id=10127 From noreply@sourceforge.net Thu Sep 12 18:16:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 10:16:20 -0700 Subject: [Expat-bugs] [ expat-Bugs-608484 ] redundant namespace declaration Message-ID: Bugs item #608484, was opened at 2002-09-12 13:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=608484&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: redundant namespace declaration Initial Comment: A redundant namespace declaration in a single element, such as: cause the parser to crash in any case. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-12 13:16 Message: Logged In: YES user_id=290026 What do you mean with crash? Expat returned a "duplicate attribute error" when I tested that. That seems correct to me, since attributes are supposed to be unique. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=608484&group_id=10127 From noreply@sourceforge.net Sun Sep 15 17:28:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Sep 2002 09:28:10 -0700 Subject: [Expat-bugs] [ expat-Bugs-609603 ] v1.95.5 Win32 static lib symbol problem Message-ID: Bugs item #609603, was opened at 2002-09-15 09:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=609603&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: v1.95.5 Win32 static lib symbol problem Initial Comment: I just switched over to using the Win32 static lib version of Expat in my MSVC++ application. Now, it appears that the following line: #define _STATIC is required before #include "expat.h" otherwise, the link fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=609603&group_id=10127 From noreply@sourceforge.net Sun Sep 15 17:29:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Sep 2002 09:29:18 -0700 Subject: [Expat-bugs] [ expat-Bugs-609603 ] v1.95.5 Win32 static lib symbol problem Message-ID: Bugs item #609603, was opened at 2002-09-15 09:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=609603&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: v1.95.5 Win32 static lib symbol problem Initial Comment: I just switched over to using the Win32 static lib version of Expat in my MSVC++ application. Now, it appears that the following line: #define _STATIC is required before #include "expat.h" otherwise, the link fails. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-15 09:29 Message: Logged In: NO ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=609603&group_id=10127 From noreply@sourceforge.net Sun Sep 15 17:50:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Sep 2002 09:50:47 -0700 Subject: [Expat-bugs] [ expat-Bugs-609603 ] v1.95.5 Win32 static lib symbol problem Message-ID: Bugs item #609603, was opened at 2002-09-15 12:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=609603&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: v1.95.5 Win32 static lib symbol problem Initial Comment: I just switched over to using the Win32 static lib version of Expat in my MSVC++ application. Now, it appears that the following line: #define _STATIC is required before #include "expat.h" otherwise, the link fails. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-15 12:50 Message: Logged In: YES user_id=290026 Either that, or you define _STATIC in the Project Settings. Have a look at the "elements" demo project, it is statically linked. However, I think it is not enough to just have the demo project, we should document this as well. I'll assign this to Fred, since the documentation needs to include static linking instructions for Unix systems too. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-15 12:29 Message: Logged In: NO ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=609603&group_id=10127 From noreply@sourceforge.net Thu Sep 19 14:49:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 06:49:09 -0700 Subject: [Expat-bugs] [ expat-Bugs-608476 ] libexpat crashed Message-ID: Bugs item #608476, was opened at 2002-09-12 13:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=608476&group_id=10127 >Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: libexpat crashed Initial Comment: An exception is caused when the message to be parsed is not wellformed in such a specific way: the "<" for the root element is missing. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-19 09:49 Message: Logged In: YES user_id=290026 Since I cannot reproduce an error, and since the original poster didn't follow up with details, this item is closed. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-12 13:13 Message: Logged In: YES user_id=290026 What do you mean? Expat is supposed to return an error in such a case. Or do you mean a memory access violation? Btw, Expat itself is written in C and therefore does not throw exceptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=608476&group_id=10127 From noreply@sourceforge.net Thu Sep 19 14:50:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 06:50:47 -0700 Subject: [Expat-bugs] [ expat-Bugs-608484 ] redundant namespace declaration Message-ID: Bugs item #608484, was opened at 2002-09-12 13:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=608484&group_id=10127 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: redundant namespace declaration Initial Comment: A redundant namespace declaration in a single element, such as: cause the parser to crash in any case. ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-19 09:50 Message: Logged In: YES user_id=290026 Since I cannot reproduce an error, and since the original poster did not follow up with details, this item is closed. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-12 13:16 Message: Logged In: YES user_id=290026 What do you mean with crash? Expat returned a "duplicate attribute error" when I tested that. That seems correct to me, since attributes are supposed to be unique. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=608484&group_id=10127 From noreply@sourceforge.net Thu Sep 26 17:07:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 09:07:35 -0700 Subject: [Expat-bugs] [ expat-Bugs-615028 ] (expat-1.95.5) Solaris 2.6 make error Message-ID: Bugs item #615028, was opened at 2002-09-26 09:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615028&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: (expat-1.95.5) Solaris 2.6 make error Initial Comment: Hi, I am trying to install expat and get the following error when runnng "make" under the expat directory. /bin/ksh ./libtool --silent --mode=link cc -g -I./lib -I. -o xmlwf/xmlwf xmlw f/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la cc: Can't exec /opt/SUNWspro/bin/../SC4.2/bin/ild *** Error code 100 make: Fatal error: Command failed for target `xmlwf/xmlwf' I have no idea where/what the "ild" command is. Any ideas? Thanks. Alan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615028&group_id=10127 From noreply@sourceforge.net Thu Sep 26 23:51:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 15:51:49 -0700 Subject: [Expat-bugs] [ expat-Bugs-615272 ] Expat 1.95.5 static library name Message-ID: Bugs item #615272, was opened at 2002-09-26 15:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615272&group_id=10127 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Expat 1.95.5 static library name Initial Comment: Expat 1.95.5 on Win32 using MSVC. I think its great that you include a static library now! It would be more convenient for our build environment though if you called the static .lib files something different than the DLL stub .lib files so that they can live in the same directory. Of course, anyone building expat could do this, but it would be nice to have it this way out of the box. You could then move these files into the "Libs" directory, and delete the "StaticLibs" directory. For other libraries, I've seen "static" appended to the name. Another thing that is often done with MSVC static libraries is to have multiple version based on how you link with the CRT - /MT (Multithreaded) or /MD (Multithreaded DLL) - and to append MT or MD to the name. This way you can use the appropriate static library depending on your situation. It's also common to keep everything in one .dsp, and use multiple configurations. So instead of 4 .dsp files, you'd have 1 .dsp with the configurations: Win32 Debug DLL (libexpat.dll and stub libexpat.lib) Win32 Debug Static MT (static libexpatMT.lib) Win32 Debug Static MD (static libexpatMD.lib) Win32 Release DLL (libexpat.dll and stub libexpat.lib) Win32 Release Static MT (static libexpatMT.lib) Win32 Release Static MD (static libexpatMD.lib) Win32 Unicode Debug DLL (libexpatw.dll and stub libexpatw.lib) Win32 Unicode Debug Static MT (static libexpatwMT.lib) Win32 Unicode Debug Static MD (static libexpatwMD.lib) Win32 Unicode Release DLL (libexpatw.dll and stub libexpatw.lib) Win32 Unicode Release Static MT (static libexpatwMT.lib) Win32 Unicode Release Static MD (static libexpatwMD.lib) It would also be nice if instead of needing to define "_STATIC", it was something a little more specific like "_EXPAT_STATIC" or even "XML_STATIC". Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615272&group_id=10127 From noreply@sourceforge.net Fri Sep 27 01:33:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 17:33:15 -0700 Subject: [Expat-bugs] [ expat-Bugs-615272 ] Expat 1.95.5 static library name Message-ID: Bugs item #615272, was opened at 2002-09-26 18:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615272&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Expat 1.95.5 static library name Initial Comment: Expat 1.95.5 on Win32 using MSVC. I think its great that you include a static library now! It would be more convenient for our build environment though if you called the static .lib files something different than the DLL stub .lib files so that they can live in the same directory. Of course, anyone building expat could do this, but it would be nice to have it this way out of the box. You could then move these files into the "Libs" directory, and delete the "StaticLibs" directory. For other libraries, I've seen "static" appended to the name. Another thing that is often done with MSVC static libraries is to have multiple version based on how you link with the CRT - /MT (Multithreaded) or /MD (Multithreaded DLL) - and to append MT or MD to the name. This way you can use the appropriate static library depending on your situation. It's also common to keep everything in one .dsp, and use multiple configurations. So instead of 4 .dsp files, you'd have 1 .dsp with the configurations: Win32 Debug DLL (libexpat.dll and stub libexpat.lib) Win32 Debug Static MT (static libexpatMT.lib) Win32 Debug Static MD (static libexpatMD.lib) Win32 Release DLL (libexpat.dll and stub libexpat.lib) Win32 Release Static MT (static libexpatMT.lib) Win32 Release Static MD (static libexpatMD.lib) Win32 Unicode Debug DLL (libexpatw.dll and stub libexpatw.lib) Win32 Unicode Debug Static MT (static libexpatwMT.lib) Win32 Unicode Debug Static MD (static libexpatwMD.lib) Win32 Unicode Release DLL (libexpatw.dll and stub libexpatw.lib) Win32 Unicode Release Static MT (static libexpatwMT.lib) Win32 Unicode Release Static MD (static libexpatwMD.lib) It would also be nice if instead of needing to define "_STATIC", it was something a little more specific like "_EXPAT_STATIC" or even "XML_STATIC". Thanks! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-26 19:39 Message: Logged In: YES user_id=290026 Since you already seem to know exactly what to do, why don't you submit a patch with these changes? We would certainly have a look at it, and there is a good chance it could be included in the next release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615272&group_id=10127 From noreply@sourceforge.net Fri Sep 27 01:33:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 17:33:57 -0700 Subject: [Expat-bugs] [ expat-Bugs-615272 ] Expat 1.95.5 static library name Message-ID: Bugs item #615272, was opened at 2002-09-26 18:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615272&group_id=10127 Category: None >Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Karl Waclawek (kwaclaw) Summary: Expat 1.95.5 static library name Initial Comment: Expat 1.95.5 on Win32 using MSVC. I think its great that you include a static library now! It would be more convenient for our build environment though if you called the static .lib files something different than the DLL stub .lib files so that they can live in the same directory. Of course, anyone building expat could do this, but it would be nice to have it this way out of the box. You could then move these files into the "Libs" directory, and delete the "StaticLibs" directory. For other libraries, I've seen "static" appended to the name. Another thing that is often done with MSVC static libraries is to have multiple version based on how you link with the CRT - /MT (Multithreaded) or /MD (Multithreaded DLL) - and to append MT or MD to the name. This way you can use the appropriate static library depending on your situation. It's also common to keep everything in one .dsp, and use multiple configurations. So instead of 4 .dsp files, you'd have 1 .dsp with the configurations: Win32 Debug DLL (libexpat.dll and stub libexpat.lib) Win32 Debug Static MT (static libexpatMT.lib) Win32 Debug Static MD (static libexpatMD.lib) Win32 Release DLL (libexpat.dll and stub libexpat.lib) Win32 Release Static MT (static libexpatMT.lib) Win32 Release Static MD (static libexpatMD.lib) Win32 Unicode Debug DLL (libexpatw.dll and stub libexpatw.lib) Win32 Unicode Debug Static MT (static libexpatwMT.lib) Win32 Unicode Debug Static MD (static libexpatwMD.lib) Win32 Unicode Release DLL (libexpatw.dll and stub libexpatw.lib) Win32 Unicode Release Static MT (static libexpatwMT.lib) Win32 Unicode Release Static MD (static libexpatwMD.lib) It would also be nice if instead of needing to define "_STATIC", it was something a little more specific like "_EXPAT_STATIC" or even "XML_STATIC". Thanks! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-26 19:39 Message: Logged In: YES user_id=290026 Since you already seem to know exactly what to do, why don't you submit a patch with these changes? We would certainly have a look at it, and there is a good chance it could be included in the next release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615272&group_id=10127 From noreply@sourceforge.net Fri Sep 27 19:06:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Sep 2002 11:06:45 -0700 Subject: [Expat-bugs] [ expat-Bugs-615606 ] Buffer overrun with XML_ParserCreateNS Message-ID: Bugs item #615606, was opened at 2002-09-27 11:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127 Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Daniel Bowen (daniel_bowen) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overrun with XML_ParserCreateNS Initial Comment: Expat 1.95.5 on Win32 using MSVC 6, 7 A buffer overrun occurs under the following set of circumstances: * In a test program, create an XML_Parser using XML_ParserCreateNS (instead of XML_ParserCreate) * Parse a file (or stdin) where the number of bytes is greater than the size of your buffer (so that you have to do multiple passes). It seems to happen with both XML_GetBuffer / XML_ParseBuffer as well as allocating your own buffer and calling XML_Parse. To see that an error occurs: * Compile a debug version of expat (DLL or static library) * Compile a debug version of your test program that uses the debug version of expat * You get a dialog similar to the following: --------------------------- Microsoft Visual C++ Debug Library --------------------------- Debug Error! Program: ...\Expat-1.95.5 \Source\examples\Debug\elements.exe DAMAGE: after Normal block (#88) at 0x002F7798. (Press Retry to debug the application) --------------------------- Abort Retry Ignore --------------------------- If you click "Retry", it takes you to the _free_dbg function in dbgheap.c, line 1066 in MSVC 6, as a result of a "CheckBytes" call. The call stack indicates that this is on the "XML_ParserFree" call. In the output window, it lists a handful of addresses where the bytes should be "0xFD", such as: memory check error at 0x002F77BF = 0x69, should be 0xFD. If you view memory at this address, you see parts of the input XML file have been written there. If you set a breakpoint to break when data at this location in memory changes, you break at line 2110 in xmlparse.c in the function doContent, at the line: /* don't need to check for space - already done in storeAtts() */ while (*localPart) *uri++ = *localPart++; If you watch memory changing as you do multiple passes through XML_Parse/XML_ParseBuffer, it seems that instead of reusing the internal buffer starting at the beginning, the internal buffer keeps getting appended to (beyond the size of its allocation). This should be easily reproducable. For example, in the "elements" sample, change the "XML_ParserCreate (NULL)" line on line 32 in elements.c to "XML_ParserCreateNS(NULL, '|')". I haven't tested this scenario in builds other than 1.95.5, so I'm not sure if this is a new bug or a bug that hasn't yet been tripped across. Thanks! -Daniel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127 From noreply@sourceforge.net Fri Sep 27 19:30:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Sep 2002 11:30:56 -0700 Subject: [Expat-bugs] [ expat-Bugs-615606 ] Buffer overrun with XML_ParserCreateNS Message-ID: Bugs item #615606, was opened at 2002-09-27 14:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127 Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Daniel Bowen (daniel_bowen) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overrun with XML_ParserCreateNS Initial Comment: Expat 1.95.5 on Win32 using MSVC 6, 7 A buffer overrun occurs under the following set of circumstances: * In a test program, create an XML_Parser using XML_ParserCreateNS (instead of XML_ParserCreate) * Parse a file (or stdin) where the number of bytes is greater than the size of your buffer (so that you have to do multiple passes). It seems to happen with both XML_GetBuffer / XML_ParseBuffer as well as allocating your own buffer and calling XML_Parse. To see that an error occurs: * Compile a debug version of expat (DLL or static library) * Compile a debug version of your test program that uses the debug version of expat * You get a dialog similar to the following: --------------------------- Microsoft Visual C++ Debug Library --------------------------- Debug Error! Program: ...\Expat-1.95.5 \Source\examples\Debug\elements.exe DAMAGE: after Normal block (#88) at 0x002F7798. (Press Retry to debug the application) --------------------------- Abort Retry Ignore --------------------------- If you click "Retry", it takes you to the _free_dbg function in dbgheap.c, line 1066 in MSVC 6, as a result of a "CheckBytes" call. The call stack indicates that this is on the "XML_ParserFree" call. In the output window, it lists a handful of addresses where the bytes should be "0xFD", such as: memory check error at 0x002F77BF = 0x69, should be 0xFD. If you view memory at this address, you see parts of the input XML file have been written there. If you set a breakpoint to break when data at this location in memory changes, you break at line 2110 in xmlparse.c in the function doContent, at the line: /* don't need to check for space - already done in storeAtts() */ while (*localPart) *uri++ = *localPart++; If you watch memory changing as you do multiple passes through XML_Parse/XML_ParseBuffer, it seems that instead of reusing the internal buffer starting at the beginning, the internal buffer keeps getting appended to (beyond the size of its allocation). This should be easily reproducable. For example, in the "elements" sample, change the "XML_ParserCreate (NULL)" line on line 32 in elements.c to "XML_ParserCreateNS(NULL, '|')". I haven't tested this scenario in builds other than 1.95.5, so I'm not sure if this is a new bug or a bug that hasn't yet been tripped across. Thanks! -Daniel ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-27 14:30 Message: Logged In: YES user_id=290026 I am using XML_ParserCreateNS with multiple buffers all the time and have never had that problem. Could you please attach a complete but simple test case, so that we can reproduce the error. Thanks, Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127 From noreply@sourceforge.net Fri Sep 27 20:02:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Sep 2002 12:02:38 -0700 Subject: [Expat-bugs] [ expat-Bugs-615606 ] Buffer overrun with XML_ParserCreateNS Message-ID: Bugs item #615606, was opened at 2002-09-27 11:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127 Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Daniel Bowen (daniel_bowen) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overrun with XML_ParserCreateNS Initial Comment: Expat 1.95.5 on Win32 using MSVC 6, 7 A buffer overrun occurs under the following set of circumstances: * In a test program, create an XML_Parser using XML_ParserCreateNS (instead of XML_ParserCreate) * Parse a file (or stdin) where the number of bytes is greater than the size of your buffer (so that you have to do multiple passes). It seems to happen with both XML_GetBuffer / XML_ParseBuffer as well as allocating your own buffer and calling XML_Parse. To see that an error occurs: * Compile a debug version of expat (DLL or static library) * Compile a debug version of your test program that uses the debug version of expat * You get a dialog similar to the following: --------------------------- Microsoft Visual C++ Debug Library --------------------------- Debug Error! Program: ...\Expat-1.95.5 \Source\examples\Debug\elements.exe DAMAGE: after Normal block (#88) at 0x002F7798. (Press Retry to debug the application) --------------------------- Abort Retry Ignore --------------------------- If you click "Retry", it takes you to the _free_dbg function in dbgheap.c, line 1066 in MSVC 6, as a result of a "CheckBytes" call. The call stack indicates that this is on the "XML_ParserFree" call. In the output window, it lists a handful of addresses where the bytes should be "0xFD", such as: memory check error at 0x002F77BF = 0x69, should be 0xFD. If you view memory at this address, you see parts of the input XML file have been written there. If you set a breakpoint to break when data at this location in memory changes, you break at line 2110 in xmlparse.c in the function doContent, at the line: /* don't need to check for space - already done in storeAtts() */ while (*localPart) *uri++ = *localPart++; If you watch memory changing as you do multiple passes through XML_Parse/XML_ParseBuffer, it seems that instead of reusing the internal buffer starting at the beginning, the internal buffer keeps getting appended to (beyond the size of its allocation). This should be easily reproducable. For example, in the "elements" sample, change the "XML_ParserCreate (NULL)" line on line 32 in elements.c to "XML_ParserCreateNS(NULL, '|')". I haven't tested this scenario in builds other than 1.95.5, so I'm not sure if this is a new bug or a bug that hasn't yet been tripped across. Thanks! -Daniel ---------------------------------------------------------------------- >Comment By: Daniel Bowen (daniel_bowen) Date: 2002-09-27 12:02 Message: Logged In: YES user_id=619351 I've attached a copy of the "elements" project along with the expat (static) that it uses. I compiled both in debug, and included in the upload elements.exe. Also in the examples\Debug directory is an XML file that will trigger the bug. I had tried it with only a couple of input XML files. I've tried it with a few more, and I see that to reproduce the problem is not always as simple as "Parse a file (or stdin) where the number of bytes is greater than the size of your buffer". I'm not sure what characteristics trigger the bug, but from what I could tell, this was at least one symptom. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-27 11:30 Message: Logged In: YES user_id=290026 I am using XML_ParserCreateNS with multiple buffers all the time and have never had that problem. Could you please attach a complete but simple test case, so that we can reproduce the error. Thanks, Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127 From noreply@sourceforge.net Fri Sep 27 20:09:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Sep 2002 12:09:11 -0700 Subject: [Expat-bugs] [ expat-Bugs-615606 ] Buffer overrun with XML_ParserCreateNS Message-ID: Bugs item #615606, was opened at 2002-09-27 11:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127 Category: None Group: Test Required Status: Open Resolution: None Priority: 5 Submitted By: Daniel Bowen (daniel_bowen) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overrun with XML_ParserCreateNS Initial Comment: Expat 1.95.5 on Win32 using MSVC 6, 7 A buffer overrun occurs under the following set of circumstances: * In a test program, create an XML_Parser using XML_ParserCreateNS (instead of XML_ParserCreate) * Parse a file (or stdin) where the number of bytes is greater than the size of your buffer (so that you have to do multiple passes). It seems to happen with both XML_GetBuffer / XML_ParseBuffer as well as allocating your own buffer and calling XML_Parse. To see that an error occurs: * Compile a debug version of expat (DLL or static library) * Compile a debug version of your test program that uses the debug version of expat * You get a dialog similar to the following: --------------------------- Microsoft Visual C++ Debug Library --------------------------- Debug Error! Program: ...\Expat-1.95.5 \Source\examples\Debug\elements.exe DAMAGE: after Normal block (#88) at 0x002F7798. (Press Retry to debug the application) --------------------------- Abort Retry Ignore --------------------------- If you click "Retry", it takes you to the _free_dbg function in dbgheap.c, line 1066 in MSVC 6, as a result of a "CheckBytes" call. The call stack indicates that this is on the "XML_ParserFree" call. In the output window, it lists a handful of addresses where the bytes should be "0xFD", such as: memory check error at 0x002F77BF = 0x69, should be 0xFD. If you view memory at this address, you see parts of the input XML file have been written there. If you set a breakpoint to break when data at this location in memory changes, you break at line 2110 in xmlparse.c in the function doContent, at the line: /* don't need to check for space - already done in storeAtts() */ while (*localPart) *uri++ = *localPart++; If you watch memory changing as you do multiple passes through XML_Parse/XML_ParseBuffer, it seems that instead of reusing the internal buffer starting at the beginning, the internal buffer keeps getting appended to (beyond the size of its allocation). This should be easily reproducable. For example, in the "elements" sample, change the "XML_ParserCreate (NULL)" line on line 32 in elements.c to "XML_ParserCreateNS(NULL, '|')". I haven't tested this scenario in builds other than 1.95.5, so I'm not sure if this is a new bug or a bug that hasn't yet been tripped across. Thanks! -Daniel ---------------------------------------------------------------------- >Comment By: Daniel Bowen (daniel_bowen) Date: 2002-09-27 12:09 Message: Logged In: YES user_id=619351 I had to re-upload with the compiled elements.exe taken out (it made the file too big to upload). You can just rebuild all in debug mode. ---------------------------------------------------------------------- Comment By: Daniel Bowen (daniel_bowen) Date: 2002-09-27 12:02 Message: Logged In: YES user_id=619351 I've attached a copy of the "elements" project along with the expat (static) that it uses. I compiled both in debug, and included in the upload elements.exe. Also in the examples\Debug directory is an XML file that will trigger the bug. I had tried it with only a couple of input XML files. I've tried it with a few more, and I see that to reproduce the problem is not always as simple as "Parse a file (or stdin) where the number of bytes is greater than the size of your buffer". I'm not sure what characteristics trigger the bug, but from what I could tell, this was at least one symptom. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-27 11:30 Message: Logged In: YES user_id=290026 I am using XML_ParserCreateNS with multiple buffers all the time and have never had that problem. Could you please attach a complete but simple test case, so that we can reproduce the error. Thanks, Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127 From noreply@sourceforge.net Sat Sep 28 09:43:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Sep 2002 01:43:04 -0700 Subject: [Expat-bugs] [ expat-Bugs-615815 ] Can not build expat-1.95.5.tar.gz Message-ID: Bugs item #615815, was opened at 2002-09-28 03:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615815&group_id=10127 Category: Build control Group: Platform Specific Status: Open Resolution: None Priority: 5 Submitted By: Guy Adani (guyad11) Assigned to: Greg Stein (gstein) Summary: Can not build expat-1.95.5.tar.gz Initial Comment: I have downloaded expat-1.95.5.tar.gz to my PC, which has cygwin installed. According to the docs, I can install like I am running on a UNIX machine : "Building under Win32 If you're using the GNU compiler under cygwin, follow the Unix directions in the next section. Otherwise if you have Microsoft's Developer Studio installed, then from Windows Explorer double- click on "expat.dsp" in the lib directory and build and install in the usual manner." After running configure, I run make and got the following error: "$ make /bin/bash ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing- prototypes - Wstrict-prototypes -fexceptions -I./lib -I. -no-undefined -version- info 4:0:4 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole. lo /usr/lib/libcygwin.a(libcmain.o)(.text+0x6a): undefined reference to `WinMain@16 ' collect2: ld returned 1 exit status make: *** [libexpat.la] Error 1 " What do I need to do to install ? Attached is the configure log file. Thanks, Guy Adani ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615815&group_id=10127 From noreply@sourceforge.net Sat Sep 28 15:56:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Sep 2002 07:56:56 -0700 Subject: [Expat-bugs] [ expat-Bugs-615606 ] Buffer overrun with XML_ParserCreateNS Message-ID: Bugs item #615606, was opened at 2002-09-27 14:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127 Category: None Group: Test Required Status: Open >Resolution: Fixed Priority: 5 Submitted By: Daniel Bowen (daniel_bowen) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overrun with XML_ParserCreateNS Initial Comment: Expat 1.95.5 on Win32 using MSVC 6, 7 A buffer overrun occurs under the following set of circumstances: * In a test program, create an XML_Parser using XML_ParserCreateNS (instead of XML_ParserCreate) * Parse a file (or stdin) where the number of bytes is greater than the size of your buffer (so that you have to do multiple passes). It seems to happen with both XML_GetBuffer / XML_ParseBuffer as well as allocating your own buffer and calling XML_Parse. To see that an error occurs: * Compile a debug version of expat (DLL or static library) * Compile a debug version of your test program that uses the debug version of expat * You get a dialog similar to the following: --------------------------- Microsoft Visual C++ Debug Library --------------------------- Debug Error! Program: ...\Expat-1.95.5 \Source\examples\Debug\elements.exe DAMAGE: after Normal block (#88) at 0x002F7798. (Press Retry to debug the application) --------------------------- Abort Retry Ignore --------------------------- If you click "Retry", it takes you to the _free_dbg function in dbgheap.c, line 1066 in MSVC 6, as a result of a "CheckBytes" call. The call stack indicates that this is on the "XML_ParserFree" call. In the output window, it lists a handful of addresses where the bytes should be "0xFD", such as: memory check error at 0x002F77BF = 0x69, should be 0xFD. If you view memory at this address, you see parts of the input XML file have been written there. If you set a breakpoint to break when data at this location in memory changes, you break at line 2110 in xmlparse.c in the function doContent, at the line: /* don't need to check for space - already done in storeAtts() */ while (*localPart) *uri++ = *localPart++; If you watch memory changing as you do multiple passes through XML_Parse/XML_ParseBuffer, it seems that instead of reusing the internal buffer starting at the beginning, the internal buffer keeps getting appended to (beyond the size of its allocation). This should be easily reproducable. For example, in the "elements" sample, change the "XML_ParserCreate (NULL)" line on line 32 in elements.c to "XML_ParserCreateNS(NULL, '|')". I haven't tested this scenario in builds other than 1.95.5, so I'm not sure if this is a new bug or a bug that hasn't yet been tripped across. Thanks! -Daniel ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-28 10:56 Message: Logged In: YES user_id=290026 I could trace this bug to the function storeRawNames. What happens is this: when namespace processing is turned on, tag->name.str does not point to tag->buf, but to the binding->uri buffer of the associated PREFIX structure. Therefore, when tag->buf is reallocated, one should update tag->name.str only when namespace processing is off. This condition was not tested and tag->name.str was wrongly updated in those cases when namespace processing was turned on and the storeRawNames function reallocated tag->buf. Fix is already committed to CVS. Patch attached. I tested with your example and it works fine now. ---------------------------------------------------------------------- Comment By: Daniel Bowen (daniel_bowen) Date: 2002-09-27 15:09 Message: Logged In: YES user_id=619351 I had to re-upload with the compiled elements.exe taken out (it made the file too big to upload). You can just rebuild all in debug mode. ---------------------------------------------------------------------- Comment By: Daniel Bowen (daniel_bowen) Date: 2002-09-27 15:02 Message: Logged In: YES user_id=619351 I've attached a copy of the "elements" project along with the expat (static) that it uses. I compiled both in debug, and included in the upload elements.exe. Also in the examples\Debug directory is an XML file that will trigger the bug. I had tried it with only a couple of input XML files. I've tried it with a few more, and I see that to reproduce the problem is not always as simple as "Parse a file (or stdin) where the number of bytes is greater than the size of your buffer". I'm not sure what characteristics trigger the bug, but from what I could tell, this was at least one symptom. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-27 14:30 Message: Logged In: YES user_id=290026 I am using XML_ParserCreateNS with multiple buffers all the time and have never had that problem. Could you please attach a complete but simple test case, so that we can reproduce the error. Thanks, Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127 From noreply@sourceforge.net Sun Sep 29 02:15:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Sep 2002 18:15:59 -0700 Subject: [Expat-bugs] [ expat-Bugs-615606 ] Buffer overrun with XML_ParserCreateNS Message-ID: Bugs item #615606, was opened at 2002-09-27 11:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127 Category: None Group: Test Required Status: Open Resolution: Fixed Priority: 5 Submitted By: Daniel Bowen (daniel_bowen) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overrun with XML_ParserCreateNS Initial Comment: Expat 1.95.5 on Win32 using MSVC 6, 7 A buffer overrun occurs under the following set of circumstances: * In a test program, create an XML_Parser using XML_ParserCreateNS (instead of XML_ParserCreate) * Parse a file (or stdin) where the number of bytes is greater than the size of your buffer (so that you have to do multiple passes). It seems to happen with both XML_GetBuffer / XML_ParseBuffer as well as allocating your own buffer and calling XML_Parse. To see that an error occurs: * Compile a debug version of expat (DLL or static library) * Compile a debug version of your test program that uses the debug version of expat * You get a dialog similar to the following: --------------------------- Microsoft Visual C++ Debug Library --------------------------- Debug Error! Program: ...\Expat-1.95.5 \Source\examples\Debug\elements.exe DAMAGE: after Normal block (#88) at 0x002F7798. (Press Retry to debug the application) --------------------------- Abort Retry Ignore --------------------------- If you click "Retry", it takes you to the _free_dbg function in dbgheap.c, line 1066 in MSVC 6, as a result of a "CheckBytes" call. The call stack indicates that this is on the "XML_ParserFree" call. In the output window, it lists a handful of addresses where the bytes should be "0xFD", such as: memory check error at 0x002F77BF = 0x69, should be 0xFD. If you view memory at this address, you see parts of the input XML file have been written there. If you set a breakpoint to break when data at this location in memory changes, you break at line 2110 in xmlparse.c in the function doContent, at the line: /* don't need to check for space - already done in storeAtts() */ while (*localPart) *uri++ = *localPart++; If you watch memory changing as you do multiple passes through XML_Parse/XML_ParseBuffer, it seems that instead of reusing the internal buffer starting at the beginning, the internal buffer keeps getting appended to (beyond the size of its allocation). This should be easily reproducable. For example, in the "elements" sample, change the "XML_ParserCreate (NULL)" line on line 32 in elements.c to "XML_ParserCreateNS(NULL, '|')". I haven't tested this scenario in builds other than 1.95.5, so I'm not sure if this is a new bug or a bug that hasn't yet been tripped across. Thanks! -Daniel ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-28 18:15 Message: Logged In: NO Ouch! I've been working for the past two days tracking down this bug. Thanks for the patch! ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-28 07:56 Message: Logged In: YES user_id=290026 I could trace this bug to the function storeRawNames. What happens is this: when namespace processing is turned on, tag->name.str does not point to tag->buf, but to the binding->uri buffer of the associated PREFIX structure. Therefore, when tag->buf is reallocated, one should update tag->name.str only when namespace processing is off. This condition was not tested and tag->name.str was wrongly updated in those cases when namespace processing was turned on and the storeRawNames function reallocated tag->buf. Fix is already committed to CVS. Patch attached. I tested with your example and it works fine now. ---------------------------------------------------------------------- Comment By: Daniel Bowen (daniel_bowen) Date: 2002-09-27 12:09 Message: Logged In: YES user_id=619351 I had to re-upload with the compiled elements.exe taken out (it made the file too big to upload). You can just rebuild all in debug mode. ---------------------------------------------------------------------- Comment By: Daniel Bowen (daniel_bowen) Date: 2002-09-27 12:02 Message: Logged In: YES user_id=619351 I've attached a copy of the "elements" project along with the expat (static) that it uses. I compiled both in debug, and included in the upload elements.exe. Also in the examples\Debug directory is an XML file that will trigger the bug. I had tried it with only a couple of input XML files. I've tried it with a few more, and I see that to reproduce the problem is not always as simple as "Parse a file (or stdin) where the number of bytes is greater than the size of your buffer". I'm not sure what characteristics trigger the bug, but from what I could tell, this was at least one symptom. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2002-09-27 11:30 Message: Logged In: YES user_id=290026 I am using XML_ParserCreateNS with multiple buffers all the time and have never had that problem. Could you please attach a complete but simple test case, so that we can reproduce the error. Thanks, Karl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=615606&group_id=10127