From matthias.maschek at uma.at Wed May 2 05:36:45 2012 From: matthias.maschek at uma.at (Matthias Maschek) Date: Wed May 2 11:52:54 2012 Subject: [xsde-users] XSDE parsing crashing under Release build Message-ID: <4FA1002D.1090105@uma.at> Hello! I'm using XSDE to parse some files in my project which runs perfectly well. Except when i'm doing a release build (using QT creator). It crashes the first time I'm trying to parse anything. I'm using XSDE on Ubuntu 11.10 64Bit I post the stacktrace below. 0 raise /lib/x86_64-linux-gnu/libc.so.6 0 0x7ffff41963a5 1 abort /lib/x86_64-linux-gnu/libc.so.6 0 0x7ffff4199b0b 2 ?? /lib/x86_64-linux-gnu/libc.so.6 0 0x7ffff41cfd63 3 ?? /lib/x86_64-linux-gnu/libc.so.6 0 0x7ffff41da6e6 4 free /lib/x86_64-linux-gnu/libc.so.6 0 0x7ffff41de9cc 5 skin::Schema::ui::~ui() 0 0x52e11e 6 skin::Schema::ui_pimpl::pre() 0 0x52c3a7 7 skin::Schema::theme_pskel::sequence_0(unsigned long&, unsigned long&, xsde::cxx::ro_string const&, xsde::cxx::ro_string const&, bool) 0 0x527ca5 8 skin::Schema::theme_pskel::_start_element_impl(xsde::cxx::ro_string const&, xsde::cxx::ro_string const&) 0 0x52892d 9 xsde::cxx::parser::validating::complex_content::_start_element(xsde::cxx::ro_string const&, xsde::cxx::ro_string const&) 0 0x54fccd 10 xsde::cxx::parser::expat::document_pimpl::start_element_(char const*, char const**) 0 0x54f4bb 11 doContent 0 0x55bbc1 12 doProlog 0 0x558a86 13 prologInitProcessor 0 0x55ddac 14 XML_ParseBuffer 0 0x55fba2 15 xsde::cxx::parser::expat::document_pimpl::parse(void const*, unsigned long, bool) 0 0x54ed28 16 xsde::cxx::parser::expat::document_pimpl::parse(std::istream&) 0 0x54ee9c 17 xsde::cxx::parser::expat::document_pimpl::parse(char const*) 0 0x54f07f 18 SkinParser::parseTheme(std::string, bool) 0 0x42b366 Thanks for the Help, Matthias Maschek -- uma ? separating the signal from the noise matthias.maschek . developer . matthias.maschek@uma.at phone +43 1 526 29 67-0 . fax +43-1-526 29 67-200 uma information technology GmbH . zollergasse 9-11 . a-1070 vienna http://www.uma.at http://www.facebook.com/umavienna http://www.youtube.com/user/umavienna -- Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From boris at codesynthesis.com Thu May 3 02:51:41 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu May 3 02:48:26 2012 Subject: [xsde-users] XSDE parsing crashing under Release build In-Reply-To: <4FA1002D.1090105@uma.at> References: <4FA1002D.1090105@uma.at> Message-ID: Hi Matthias, Matthias Maschek writes: > It crashes the first time I'm trying to parse anything. > > I post the stacktrace below. > > 0 raise /lib/x86_64-linux-gnu/libc.so.6 0 0x7ffff41963a5 > 1 abort /lib/x86_64-linux-gnu/libc.so.6 0 0x7ffff4199b0b > 2 ?? /lib/x86_64-linux-gnu/libc.so.6 0 0x7ffff41cfd63 > 3 ?? /lib/x86_64-linux-gnu/libc.so.6 0 0x7ffff41da6e6 > 4 free /lib/x86_64-linux-gnu/libc.so.6 0 0x7ffff41de9cc > 5 skin::Schema::ui::~ui() 0 0x52e11e > 6 skin::Schema::ui_pimpl::pre() 0 0x52c3a7 It is hard to say what's going just by looking at the stack trace. We don't even know whether the ui and ui_pimpl classes are hand- written by you or auto-generated by XSD/e (i.e., are you using C++/Hybrid or C++/Parser). Can you at lease show the schema (if auto-generated) or C++ source (if hand-written) for these classes? Ideally, of course, I would need a small test case that reproduces the problem. Boris From boris at codesynthesis.com Thu May 3 09:27:36 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu May 3 09:24:20 2012 Subject: [xsde-users] XSDE parsing crashing under Release build In-Reply-To: <4FA25290.90003@uma.at> References: <4FA1002D.1090105@uma.at> <4FA25290.90003@uma.at> Message-ID: Hi Matthias, [CC'ed xsde-users back in.] Matthias Maschek writes: > I was able to create a small project creating the error in release mode. > I hope, it is ok to send you the zip file. Yes, thank you. I took a look and managed to trace the problem down to the _GLIBCXX_FULLY_DYNAMIC_STRING define that you have in your Makefile. If I remove this define, then everything works fine in the release mode. The reason why this define causes problem is most likely because the standard C++ library (libstdc++) that comes with your Linux distribution is not built with this configuration parameter (see the --enable-fully-dynamic-string libstdc++ configure option). So you will either need to remove this define from your Makefile (very simple fix) or you will need to compile and use a custom libstdc++ build (more complex fix). Boris From kuangzhiyong1981 at yahoo.com.cn Thu May 3 09:37:36 2012 From: kuangzhiyong1981 at yahoo.com.cn (=?utf-8?B?5b+X5YuHIOWMoQ==?=) Date: Thu May 3 10:17:14 2012 Subject: [xsde-users] xsde bug Message-ID: <1336052256.90580.YahooMailClassic@web15604.mail.cnb.yahoo.com> Dear sir: ?i use xsde to create xml parser c++ code, the bug is : ?if a element A has a base extension? B, A with element e1 while B with element e2,? then in xml A has e1 and e2 , the generated code??firstly parses e1 element in A, the state and func will not be 0, finally?e2 will get a error because it can't be parsed by base class. ? it is difficult to debug. ? please help. ? thanks. ? ? From boris at codesynthesis.com Thu May 3 10:22:34 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu May 3 10:19:16 2012 Subject: [xsde-users] xsde bug In-Reply-To: <1336052256.90580.YahooMailClassic@web15604.mail.cnb.yahoo.com> References: <1336052256.90580.YahooMailClassic@web15604.mail.cnb.yahoo.com> Message-ID: Hi, kuangzhiyong1981@yahoo.com.cn writes: > i use xsde to create xml parser c++ code, the bug is : > if a element A has a base extension B, A with element e1 while B with > element e2, then in xml A has e1 and e2 , the generated code firstly > parses e1 element in A, the state and func will not be 0, finally e2 > will get a error because it can't be parsed by base class. Can you send a small test schema (.xsd) and XML file (.xml) that reproduces this problem? Boris From Jonathan.Haws at sdl.usu.edu Tue May 22 19:01:18 2012 From: Jonathan.Haws at sdl.usu.edu (Jonathan Haws) Date: Tue May 22 19:01:28 2012 Subject: [xsde-users] Utilizing Inhertied String Classes Message-ID: I have an XSD that has facets on some attributes. For example, one attribute is an IP address and it has a facet that forces the value to be a valid IP address. Here is the XML in the XSD: Various elements reference this attribute. XSD/e generates code just fine and I can access the value of the IP address, however my problem is in that I cannot figure out how to change it. For example, if I want to serialize an XML string and add an element that should look like this: I would think all I have to do is this (this assumes that the sensor element is optional and I can have more than one in the XML): sensor sen; sen.ipaddr("10.0.0.1"); top->push_back(sen); This code does not compile because the ipaddr class is declared like this: class ipaddr: public ::std::string { public: ipaddr (); }; and all the accessor routines for those elements are declared like this: // ipaddr // const ::SMS::ipaddr& ipaddr () const; ::SMS::ipaddr& ipaddr (); void ipaddr (const ::SMS::ipaddr&); If I remove the facet, things work just fine, but I would really like to be able to verify that an IP address is valid in my code. What am I doing wrong? How can I update the IP address? I would like to avoid using things like ipaddr.clear() and ipaddr.replace() if at all possible. Thanks! Jonathan -- Jonathan R. Haws jhaws@sdl.usu.edu From ivan.lelann at free.fr Wed May 23 03:50:08 2012 From: ivan.lelann at free.fr (Ivan Le Lann) Date: Wed May 23 03:50:19 2012 Subject: [xsde-users] Utilizing Inhertied String Classes In-Reply-To: Message-ID: <898065120.157768101.1337759408572.JavaMail.root@zimbra28-e5.priv.proxad.net> ----- Mail original ----- > De: "Jonathan Haws" > ?: xsde-users@codesynthesis.com > Envoy?: Mercredi 23 Mai 2012 01:01:18 > Objet: [xsde-users] Utilizing Inhertied String Classes > > I have an XSD that has facets on some attributes. For example, one > attribute is an IP address and it has a facet that forces the value > to be a valid IP address. > > Here is the XML in the XSD: > > > > > value="((25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])" > /> > > > > > Various elements reference this attribute. XSD/e generates code just > fine and I can access the value of the IP address, however my > problem is in that I cannot figure out how to change it. > > For example, if I want to serialize an XML string and add an element > that should look like this: > > > > I would think all I have to do is this (this assumes that the sensor > element is optional and I can have more than one in the XML): > > sensor sen; > sen.ipaddr("10.0.0.1"); > top->push_back(sen); > > This code does not compile because the ipaddr class is declared like > this: > > class ipaddr: public ::std::string > { > public: > ipaddr (); > }; > > and all the accessor routines for those elements are declared like > this: > > // ipaddr > // > const ::SMS::ipaddr& > ipaddr () const; > > ::SMS::ipaddr& > ipaddr (); > > void > ipaddr (const ::SMS::ipaddr&); > > If I remove the facet, things work just fine, but I would really like > to be able to verify that an IP address is valid in my code. > > What am I doing wrong? How can I update the IP address? I would > like to avoid using things like ipaddr.clear() and ipaddr.replace() > if at all possible. > (with xsde-users in cc this time ...) I'd say: sen.ipaddr().assign("10.0.0.1"); Regards, Ivan From boris at codesynthesis.com Wed May 23 04:30:58 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed May 23 04:31:09 2012 Subject: [xsde-users] Utilizing Inhertied String Classes In-Reply-To: <898065120.157768101.1337759408572.JavaMail.root@zimbra28-e5.priv.proxad.net> References: <898065120.157768101.1337759408572.JavaMail.root@zimbra28-e5.priv.proxad.net> Message-ID: Hi Jonathan, Ivan Le Lann writes: > sen.ipaddr().assign("10.0.0.1"); Yes, Ivan's suggestion is probably the best way to do it currently. The reason we don't generate any extra constructors for types like your ipaddr is because it would require C++ exception support, which is optional in XSD/e. However, seeing that there is no reason this can't be done when C++ exceptions are enabled and also seeing that it is an often-requested feature, we will add an option in the next release of XSD/e to generate these "initialization" constructors, so that you will be able to write: ipaddr ip ("10.0.0.1"); Boris From Jonathan.Haws at sdl.usu.edu Wed May 23 09:47:36 2012 From: Jonathan.Haws at sdl.usu.edu (Jonathan Haws) Date: Wed May 23 09:47:49 2012 Subject: [xsde-users] Utilizing Inhertied String Classes In-Reply-To: References: Message-ID: <9392166f-f051-447b-b622-8296496d1b19@blur> Borus, Ivan, Thanks for the info. I am more of a C programmer, so C++ strings are a little foreign to me. Thanks for the tip. Having a constructor would be nice, but the assign method is just as easy. Thanks! Jonathan Sent from my Verizon Wireless Phone -----Original message----- From: Boris Kolpackov To: Jonathan Haws Cc: "xsde-users@codesynthesis.com" Sent: 2012 May, Wed, 23 08:31:09 GMT+00:00 Subject: Re: [xsde-users] Utilizing Inhertied String Classes Hi Jonathan, Ivan Le Lann writes: > sen.ipaddr().assign("10.0.0.1"); Yes, Ivan's suggestion is probably the best way to do it currently. The reason we don't generate any extra constructors for types like your ipaddr is because it would require C++ exception support, which is optional in XSD/e. However, seeing that there is no reason this can't be done when C++ exceptions are enabled and also seeing that it is an often-requested feature, we will add an option in the next release of XSD/e to generate these "initialization" constructors, so that you will be able to write: ipaddr ip ("10.0.0.1"); Boris From boneil at cinci.rr.com Wed May 23 10:49:25 2012 From: boneil at cinci.rr.com (Bob O'Neil) Date: Wed May 23 11:28:53 2012 Subject: [xsde-users] XSD/e Segment Fault RHEL 6 64-bit Release Mode Only Message-ID: <009a01cd38f3$3f6bf320$be43d960$@rr.com> A segment fault is generated during the execution of my application on the RHEL 6 64-bit platform (version 6.2 and 6.3) in the release build only. This has been proven true on separate platforms. I am interested in any guidance you can provide to solve this issue. My application is a Qt based console application (a Linux daemon), which depends upon two Qt libraries (QtCore and QtNetwork). The XML parsing code is auto-generated (as opposed to hand composed). This does not occur in the debug mode, or a on a more recent platform such as Fedora 16 (both debug and release). Error seems to be for the callstack within the stl basic_string destructor. The condition seems very similar to a recent posting on the board about the release build of Qt with XSD/e and libstdc++ dynamic string allocation. However, the solution posted (a define in the Makefile having to do with stl string dynamic support), I do not have in my Makefile to remove. My makefile is autogenerated from a Qt project file. The error callstack is as follows: 0 std::basic_string, std::allocator >::~basic_string() /usr/lib64/libstdc++.so.6 0 0x37dc89d4b6 1 projects::MDL::ValueUnitsType::choice1_arm(projects::MDL::ValueUnitsType::ch oice1_arm_tag) 0 0x7f7a31 2 projects::MDL::ValueUnitsType_pskel::sequence_0(unsigned long&, unsigned long&, xsde::cxx::ro_string const&, xsde::cxx::ro_string const&, bool) 0 0x782d84 3 projects::MDL::ValueUnitsType_pskel::_start_element_impl(xsde::cxx::ro_strin g const&, xsde::cxx::ro_string const&) 0 0x7831f6 4 xsde::cxx::parser::validating::complex_content::_start_element parser.cxx 300 0x89becd 5 xsde::cxx::parser::expat::document_pimpl::start_element_ document.cxx 887 0x89aa4d 6 doContent xmlparse.c 2360 0x8ac01f 7 contentProcessor xmlparse.c 2022 0x8acfa7 8 doProlog xmlparse.c 3891 0x8ae9f5 9 prologProcessor xmlparse.c 3625 0x8af9cc 10 prologInitProcessor xmlparse.c 3442 0x8af9cc 11 XML_ParseBuffer xmlparse.c 1576 0x8a4132 12 xsde::cxx::parser::expat::document_pimpl::parse document.cxx 401 0x89b5fd 13 parse document.cxx 361 0x89baf1 14 xsde::cxx::parser::expat::document_pimpl::parse document.cxx 278 0x89baf1 15 xmlParserMDL::readAndValidateXML(char const*) 0 0x44469f 16 MdlInterface::processMDL(char const*, char const*, char const*) 0 0x7e56df 17 App::mdlImportDone(bool) 0 0x86e63d 18 App::onStateUnconfiguredEntered() 0 0x42209c 19 QMetaObject::activate(QObject*, QMetaObject const*, int, void**) 0 0x9dc9c8 20 QStateMachinePrivate::enterStates(QEvent*, QList const&) 0 0x9ff580 ... Issue is on RHEL 6 platform, not Fedora 16. Under RHEL 6, the libstdc++ symbolic link is version 6.0.13. /usr/lib64/libstdc++.so.6 /usr/lib64/libstdc++.so.6.0.13 Under Fedora 16, libstdc++ is version 6.0.16. Application is based upon the Qt framework, version 4.8.1, is a console application that depends upon two Qt libraries: QtCore and Qtnetwork. An excerpt from the Makefile is as follows: ############################################################################ # # Makefile for building: debug/lmd # Generated by qmake (2.01a) (Qt 4.8.1) on: Mon May 21 00:57:49 2012 # Project: lmd.pro # Template: app # Command: /usr/local/Trolltech/Qt-4.8.1/bin/qmake -spec /usr/local/Trolltech/Qt-4.8.1/mkspecs/linux-g++ CONFIG+=debug CONFIG+=M64 CONFIG+=STATIC -o Makefile lmd.pro ############################################################################ # ####### Compiler, tools and options CC = gcc CXX = g++ DEFINES = -DM64 -DDEBUG -DQT_NETWORK_LIB -DQT_CORE_LIB CFLAGS = -pipe -g -Wall -W -D_REENTRANT $(DEFINES) CXXFLAGS = -pipe -g -Wall -W -D_REENTRANT $(DEFINES) INCPATH = -I/usr/local/Trolltech/Qt-4.8.1/mkspecs/linux-g++ -I. -I/usr/local/Trolltech/Qt-4.8.1/include/QtCore -I/usr/local/Trolltech/Qt-4.8.1/include/QtNetwork -I/usr/local/Trolltech/Qt-4.8.1/include -I/usr/include -I/opt/xsde/libxsde -I. LINK = g++ LFLAGS = LIBS = $(SUBLIBS) -L/usr/local/Trolltech/Qt-4.8.1/lib -L/opt/xsde/libxsde/xsde -lxsde -L/usr/lib64 -lnetsnmpagent -lnetsnmpmibs -lnetsnmp -lssl -lcrypto -L/lib64 -lQtNetwork -L/usr/local/Trolltech/Qt-4.8.1/lib -lQtCore -lz -lm -ldl -pthread -lgthread-2.0 -lrt -lglib-2.0 -lpthread AR = ar cqs RANLIB = QMAKE = /usr/local/Trolltech/Qt-4.8.1/bin/qmake TAR = tar -cf COMPRESS = gzip -9f COPY = cp -f SED = sed COPY_FILE = $(COPY) COPY_DIR = $(COPY) -r STRIP = strip INSTALL_FILE = install -m 644 -p INSTALL_DIR = $(COPY_DIR) INSTALL_PROGRAM = install -m 755 -p DEL_FILE = rm -f SYMLINK = ln -f -s DEL_DIR = rmdir MOVE = mv -f CHK_DIR_EXISTS= test -d MKDIR = mkdir -p Shared libraries for the static built version of the application is as follows, which is Net-SNMP libraries and operating system libraries. ldd lmd linux-vdso.so.1 => (0x00007fffdb95f000) libnetsnmpagent.so.30 => /usr/lib/libnetsnmpagent.so.30 (0x00000037d3c00000) libnetsnmpmibs.so.30 => /usr/lib/libnetsnmpmibs.so.30 (0x00007fd48738e000) libnetsnmp.so.30 => /usr/lib/libnetsnmp.so.30 (0x00000037d3400000) libssl.so.10 => /usr/lib64/libssl.so.10 (0x00000037df800000) libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00000037dd000000) libz.so.1 => /lib64/libz.so.1 (0x00000037d3000000) libdl.so.2 => /lib64/libdl.so.2 (0x00000037d2800000) libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00000037d5400000) librt.so.1 => /lib64/librt.so.1 (0x00007fd487183000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00000037d3800000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00000037d2c00000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000037dc800000) libm.so.6 => /lib64/libm.so.6 (0x00000037d2000000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000037dc000000) libc.so.6 => /lib64/libc.so.6 (0x00000037d2400000) /lib64/ld-linux-x86-64.so.2 (0x00000037d1c00000) libperl.so => /usr/lib64/perl5/CORE/libperl.so (0x00007fd486e16000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00000037d4000000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00000037e3800000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00000037e0800000) libutil.so.1 => /lib64/libutil.so.1 (0x00000037e1000000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00000037df400000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00000037de800000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00000037dcc00000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00000037de400000) libfreebl3.so => /lib64/libfreebl3.so (0x00000037e0000000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00000037dec00000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00000037dd800000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fd486bf2000) Error occurs using the following XSD/e configuration file. This is for the Linux 64-bit platform. However, the error occurs as well using an XSD/e build with the default configuration file (except for the changes to disable exceptions and setting the bit width to 64). # Toolchain. # CC := gcc CFLAGS := -m64 -pipe -g -Wall -W -D_REENTRANT -O3 CPPFLAGS := CXX := g++ CXXFLAGS := -m64 -pipe -g -Wall -W -D_REENTRANT -O3 LD := $(CXX) LDFLAGS := $(CXXFLAGS) LIBS := # Optional post-link command. The first argument to this command is # the executable name and the rest of the arguments are the object # files and libraries that were used to link this executable. # POSTLD := # Set RANLIB to empty if your system does not need ranlib. # AR := ar ARFLAGS := rc RANLIB := ranlib # Common XSD/e flags. # XSDFLAGS := --generate-inline # Platform. Valid values are: # # 'wince' - Windows CE # 'win32' - Windows 2000, XP, etc. # 'posix' - POSIX OS, including UNIX/Linux, VxWorks, etc. # XSDE_PLATFORM := posix # Platform architecture width in bits. # XSDE_ARCH_WIDTH := 64 # Platform byte order. Valid values are 'b' for big-endian and 'l' # for little-endian. # XSDE_BYTEORDER := l # Application character encoding. Valid values are 'utf8' for UTF-8 # and 'iso8859-1' for ISO-8859-1. Note that this encoding is not # the same as the XML document encoding that is being parsed or # serialized. Rather, it is the encoding that is used inside the # application. When an XML document is parsed, the character data # is automatically converted to the application encoding. Similarly, # when an XML document is serialized, the data in the application # encoding is automatically converted to the resulting document # encoding. Also don't forget to use the --char-encoding option # when compiling your schemas if using an encoding other than UTF-8. # XSDE_ENCODING := utf8 # Set to 'n' if you don't have STL (std::string, etc.). Also don't # forget to use the --no-stl option when compiling your schemas. # XSDE_STL := y # Set to 'n' if you don't want iterators to conform to the STL # requirements. This feature requires working header # and allows you to use the standard algorithms such as find_if, # etc. # XSDE_STL_ITERATOR := y # Set to 'n' if you don't have iostream. # XSDE_IOSTREAM := y # Set to 'n' if you don't have C++ exceptions. Also don't forget to # use the --no-exceptions option when compiling your schemas. # XSDE_EXCEPTIONS := n # Set to 'n' if your platform doesn't have the "long long int" type or # the strtoull function. Also don't forget to use the --no-long-long # option when compiling your schemas. # XSDE_LONGLONG := n # Set to 'n' if your platform doesn't have the snprintf function. # XSDE_SNPRINTF := y # Set to 'n' if you don't want support for XML Schema validation in # C++/Parser. Also don't forget to use the --suppress-validation # option when compiling your schemas. # XSDE_PARSER_VALIDATION := y # Set to 'n' if you don't want support for XML Schema validation in # C++/Serializer. Also don't forget to use the --suppress-validation # option when compiling your schemas. # XSDE_SERIALIZER_VALIDATION := y # Set to 'y' if you would like to have support for regular expressions in # the XSD/e runtime. If the regexp support is enabled, then the parser and # serializer validation code will use it to validate the xs:pattern facet. # If the regexp support is disabled, then this facet will be ignored. The # regexp support increases the resulting executable size by about 30-50Kb. # XSDE_REGEXP := n # Base parser/serializer implementation reuse style. Valid values are: # # 'mixin' - virtual inheritance-based reuse (specify --reuse-style-mixin) # 'tiein' - delegation-based reuse (recommended) # 'none' - no reuse support (specify --reuse-style-none) # XSDE_REUSE_STYLE := tiein # Set to 'y' if you would like the XSD/e runtime and the generated code # to perform memory management using custom allocator functions provided # by your application instead of the standard operator new/delete. Also # don't forget to use the --custom-allocator option when compiling your # schemas. See the documentation and examples for more information on # custom allocators. # XSDE_CUSTOM_ALLOCATOR := n # Set to 'y' if you would like to include the default implementation of the # custom allocator into the XSD/e runtime library. This option is primarily # useful for testing and only makes sense if XSDE_CUSTOM_ALLOCATOR is set # to 'y'. # XSDE_DEFAULT_ALLOCATOR := n # Set to 'y' if you want support for serialization of the C++/Hybrid # object model to the CDR (Common Data Representation) binary format. # This functionality requires the ACE library. # XSDE_CDR := n # Set to 'y' if you want support for serialization of the C++/Hybrid # object model to the XDR (eXternal Data Representation) binary format. # This functionality requires the XDR API which is available out of the # box on most POSIX systems as part of Sun RPC. On some systems (e.g., # (Linux, iPhone OS, VxWorks) this API is part of libc in which case # you don't need to link anything extra. On other platforms, the XDR # API may require linking to another library (which you can add to the # LIBS variable above), such as -lrpc (QNX, LynxOS) or -lnsl. On non- # POSIX platforms you may need to install a third-party library which # provides the XDR API. Also note that some older versions of the API # (e.g., those found on LynxOS) may not support serialization of the # long long type. In this case you will get a compilation error saying # that xdr_longlong_t and xdr_u_longlong_t are not declared. One way to # resolve this is to disable the use of the long long type in XSD/e (see # XSDE_LONGLONG above). # XSDE_XDR := n # Set to 'y' if you need to handle XML vocabularies that use XML Schema # polymorphism (xsi:type or substitution groups). Also don't forget to # use either --generate-polymorphic (generates polymorphism-aware code) # or --runtime-polymorphic (generates non-polymorphic code that uses the # runtime library configured with polymorphism support). Note that support # for XML Schema polymorphism requires runtime static initialization # support in the C++ compiler (that is, support for automatic calling # of constructors for static objects). Furthermore, if the mixin reuse # style is used (XSDE_REUSE_STYLE) then the generated code requires # support for dynamic_cast. # XSDE_POLYMORPHIC := n # When polymorphism support is enabled (XSDE_POLYMORPHIC), the following # parameters control the substitution and inheritance hashmaps bucket # allocation. Because the number of elements in these hashmaps depends # on the schemas being compiled and thus is fairly static, these hashmaps # do not perform automatic table resizing. To obtain good performance the # elements to buckets ratio should be between 0.7 and 0.9. The recommended # way to ensure this range is to add diagnostics code to your application # as shown in the documentation and examples. It is also a good idea to # use prime numbers for bucket counts: 53 97 193 389 769 1543 3079 6151 # 12289 24593 49157 98317 196613 393241. Inheritance hashmaps are only # used when validation is enabled. # XSDE_PARSER_SMAP_BUCKETS := 53 XSDE_PARSER_IMAP_BUCKETS := 97 XSDE_SERIALIZER_SMAP_BUCKETS := 53 XSDE_SERIALIZER_SMAP_BUCKET_BUCKETS := 53 XSDE_SERIALIZER_IMAP_BUCKETS := 97 # Options tuning depending on the features selected. # ifeq ($(XSDE_EXCEPTIONS),y) CFLAGS += -fexceptions endif From boris at codesynthesis.com Wed May 23 12:03:31 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed May 23 12:03:39 2012 Subject: [xsde-users] XSD/e Segment Fault RHEL 6 64-bit Release Mode Only In-Reply-To: <009a01cd38f3$3f6bf320$be43d960$@rr.com> References: <009a01cd38f3$3f6bf320$be43d960$@rr.com> Message-ID: Hi Bob, Bob O'Neil writes: > A segment fault is generated during the execution of my application on the > RHEL 6 64-bit platform (version 6.2 and 6.3) in the release build only. > > I am interested in any guidance you can provide to solve this issue. > > 0 std::basic_string, std::allocator > >::~basic_string() /usr/lib64/libstdc++.so.6 0 0x37dc89d4b6 This can generally indicate one of the following things: 1. The is a memory corruption bug in the application. 2. There is a bug in XSD/e. 3. There is a bug in the toolchain (e.g., in libstdc++) or some mis- configuration. #1 is the most likely cause and the fact that the segfault happens in basic_string's destructor points to this as well. The best way to track such errors down is to run the program under valgrind. So I suggest that you do that as your next step and see if there are any invalid reads or writes, especially in the application code. Boris From ivan.lelann at free.fr Wed May 30 05:52:01 2012 From: ivan.lelann at free.fr (Ivan Le Lann) Date: Wed May 30 05:52:12 2012 Subject: [xsde-users] add suffix to attribute getter/setter In-Reply-To: <1066063184.171171028.1338370178246.JavaMail.root@zimbra28-e5.priv.proxad.net> Message-ID: <803905248.171216108.1338371521890.JavaMail.root@zimbra28-e5.priv.proxad.net> Hi, Is there a way with XSDe/Hybrid to control generated getter/setter method names for attributes ? (without changing the xsd attribute name, obviously) Example: would give getter/setter "Name__attr" instead of "Name". Motivation: I wrapped some XML generation code in macros so that I can either use XSDe or (e.g.) pugixml. But XSDe code does not depend on the child being an attribute or an element. XML_ADD_ELEM(parent,Name,"John") would work fine with XSDe but do something wrong at runtime with pugixml. I want to make this a compile time failure with XSDe. Regards, Ivan From boris at codesynthesis.com Wed May 30 10:06:01 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed May 30 10:06:08 2012 Subject: [xsde-users] add suffix to attribute getter/setter In-Reply-To: <803905248.171216108.1338371521890.JavaMail.root@zimbra28-e5.priv.proxad.net> References: <1066063184.171171028.1338370178246.JavaMail.root@zimbra28-e5.priv.proxad.net> <803905248.171216108.1338371521890.JavaMail.root@zimbra28-e5.priv.proxad.net> Message-ID: Hi Ivan, Ivan Le Lann writes: > Is there a way with XSDe/Hybrid to control generated getter/setter > method names for attributes ? (without changing the xsd attribute > name, obviously) > > > > > > would give getter/setter "Name__attr" instead of "Name". No, there is currently no such mechanism. If the names of attributes in your schema are not used for any other constructs (e.g., type or element names), then you could achieve this using the --reserved-name option. For example: --reserved-name Name=Name__attr You could probably generate an options file with a list of these options for all of your attributes with a simple sed script. Boris