From lbandy3 at gmail.com Fri Feb 1 10:38:17 2019 From: lbandy3 at gmail.com (=?UTF-8?Q?Andr=C3=A1s_Bondor?=) Date: Fri Feb 1 11:31:35 2019 Subject: [xsd-users] How to set custom C++ base-classes when generating from an xsd file Message-ID: Hi everyone, I found this thread pretty old thread from 2006 ( https://www.codesynthesis.com/pipermail/xsd-users/2006-February/000220.html) which says there was no support for it by the time, but I assume in the past few years things might have changed. I'm working on converting a pretty big xsd scheme to c++ code with multiple types and all, and later in code I'd need to traverse the constructed tree in a way that I can implement custom actions in some of the objects/classes contained in an xml. I went trough the documentation multiple times but still I was unable to see a way to do that. I was thinking of adding a base node class as the default base so each class can inherit from this, which would be a pretty straightforward oneliner change in the generated code, however I'd still need to distinguish between different object types on the fly and write all the class login in the same place, not very OOP in my opinion. Is there any better way to do that? Since the generated code is huge, making manual adjustments to each type would be a tremendous amount of work. Also if no custom classes can be provided as base classes or a method to add custom functionality to the generated objects I could manually go trough the generated hierarchy and construct the same tree with custom objects by hand, but then in this case I could simply use a header-only xml library and do the parsing the same way I'm iterating over the generated classes anyway. Any advice is appreciated! Thank you, Andras From boris at codesynthesis.com Mon Feb 4 08:25:14 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 4 08:40:04 2019 Subject: [xsd-users] How to set custom C++ base-classes when generating from an xsd file In-Reply-To: References: Message-ID: Andr?s Bondor writes: > I went trough the documentation multiple times but still I was unable > to see a way to do that. I was thinking of adding a base node class as the > default base so each class can inherit from this [...] I think the C++/Tree Mapping Customization Guide is what you are looking for: http://wiki.codesynthesis.com/Tree/Customization_guide From jnw at xs4all.nl Sun Feb 10 12:32:13 2019 From: jnw at xs4all.nl (Jeroen N. Witmond) Date: Sun Feb 10 12:47:30 2019 Subject: [xsd-users] Extracting timezone from ::xml_schema::date_time and inserting it into Boost.Date_Time Message-ID: Greetings, Does anybody have any examples or hints on how to extract the timezone from ::xml_schema::date_time (the "Z" in "2014-01-12T08:48:54.000Z", can be a different character for a different time zone) and on how to insert this information into a Boost.Date_Time local_date_time? Thanks, Jeroen. From boris at codesynthesis.com Mon Feb 11 08:16:44 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 11 08:31:58 2019 Subject: [xsd-users] Extracting timezone from ::xml_schema::date_time and inserting it into Boost.Date_Time In-Reply-To: References: Message-ID: Jeroen N. Witmond writes: > Does anybody have any examples or hints on how to extract the timezone from > ::xml_schema::date_time (the "Z" in "2014-01-12T08:48:54.000Z", can be a > different character for a different time zone) Documentation does: https://codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.5.9 From tiaanwessels at gmail.com Tue Feb 12 06:53:41 2019 From: tiaanwessels at gmail.com (Tiaan Wessels) Date: Tue Feb 12 07:09:19 2019 Subject: [xsd-users] Seemingly bogus unstable conflict Message-ID: Hi, I am experimenting with xsdcxx on Linux to try and see if it could be useful to me. I run into a problem where it seems to think that the same type in the same xsd is in fact different types due to the way filenames get built up during parsing depending on the referencing schemas. The following illustrates this: /lab/www.w3.org/XML/2008/06/../../../2009/01/xml.xsd:43:28 : error: attribute name 'lang' creates an unstable conflict when used as a type name ../../../../../ schemas.wmo.int/iwxxm/2.1.1/../../../schemas.opengis.net/gml/3.2.1/../../../www.w3.org/XML/2008/06/../../../2009/01/xml.xsd:78:18 : info: conflicting type is defined here /lab/www.w3.org/XML/2008/06/../../../2009/01/xml.xsd:43:28 : info: use --anonymous-regex to resolve this conflict The two mentioned files are in fact the same if you resolve all the ..'s in them. Is there some command line option that I can use to resolve this? Thanks From boris at codesynthesis.com Tue Feb 12 08:22:01 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 12 08:37:19 2019 Subject: [xsd-users] Seemingly bogus unstable conflict In-Reply-To: References: Message-ID: Tiaan Wessels writes: > The two mentioned files are in fact the same if you resolve all the ..'s in > them. I vaguely remember fixing something like this for the next release. > Is there some command line option that I can use to resolve this? There are --location* options that should allow you to work around this. See xsd(1) for details. From jimson.james at intellitix.com Wed Feb 13 12:09:37 2019 From: jimson.james at intellitix.com (jimson.james@intellitix.com) Date: Wed Feb 13 12:24:57 2019 Subject: [xsd-users] Unresolved external symbol Wrapper4InputSource Message-ID: <034201d4c3be$e66d1ca0$b34755e0$@intellitix.com> I am trying to use XSD with Xerces-C-3.1.4 static libs (built with VS2017, Using QT5.9 MSVC2015x86). Got two unresolved external symbols. Since it is just two errors, I guess its not the linker pre-processor that's causing this. Wondering why xercesc_3_1::Wrapper4InputSource::Wrapper4InputSource and xercesc_3_1::Wrapper4InputSource::~Wrapper4InputSource didn't make it into the static lib. helloworld.obj:-1: error: LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall xercesc_3_1::Wrapper4InputSource::Wrapper4InputSource(class xercesc_3_1::InputSource * const,bool,class xercesc_3_1::MemoryManager * const)" (__imp_??0Wrapper4InputSource@xercesc_3_1@@QAE@QAVInputSource@1@_NQAVMemoryM anager@1@@Z) referenced in function "class std::unique_ptr > __cdecl xsd::cxx::xml::dom::parse(class xercesc_3_1::InputSource &,class xercesc_3_1::DOMErrorHandler &,class xsd::cxx::xml::properties const &,unsigned long)" (??$parse@D@dom@xml@cxx@xsd@@YA?AV?$unique_ptr@VDOMDocument@xercesc_3_1@@U?$ deleter@VDOMDocument@xercesc_3_1@@@dom@xml@cxx@xsd@@@std@@AAVInputSource@xer cesc_3_1@@AAVDOMErrorHandler@7@ABV?$properties@D@123@K@Z) helloworld.obj:-1: error: LNK2019: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall xercesc_3_1::Wrapper4InputSource::~Wrapper4InputSource(void)" (__imp_??1Wrapper4InputSource@xercesc_3_1@@UAE@XZ) referenced in function __catch$??$parse@D@dom@xml@cxx@xsd@@YA?AV?$unique_ptr@VDOMDocument@xercesc_3 _1@@U?$deleter@VDOMDocument@xercesc_3_1@@@dom@xml@cxx@xsd@@@std@@AAVInputSou rce@xercesc_3_1@@AAVDOMErrorHandler@7@ABV?$properties@D@123@K@Z$0 debug\testbed.exe:-1: error: LNK1120: 2 unresolved externals Made a stackoverflow question with all the details too, https://stackoverflow.com/questions/54674618/mtd-vs-mdd-static-linking-win32 -library-in-qt-creator Any idea why the Wrapper4InputSource module never made it into the lib??? Btw, dynamic linking workd perfect. From barnwell9 at gmail.com Wed Feb 13 08:51:36 2019 From: barnwell9 at gmail.com (Corey Barnwell) Date: Fri Feb 15 09:13:47 2019 Subject: [xsd-users] XSD C++17 Support Message-ID: Are there any plans for adding C++17 support to XSD? Seems to be riddled with auto_ptr usage. Or is XSD a dead project? I noticed it doesn't seem to have been updated since 2014. From jesus.herrera at toshibagcs.com Thu Feb 14 09:58:43 2019 From: jesus.herrera at toshibagcs.com (jesus.herrera@toshibagcs.com) Date: Fri Feb 15 09:13:47 2019 Subject: [xsd-users] Treat decimal as string Message-ID: Hi, Is there a simple way to treat xsd:decimal as strings in C++? I read the "Customizing the XML Schema built-in types" page in the "Tree/Customization guide", but std::string should not be subclassed like in the example (because no virtual destructor). I played around with the --custom-type flag. I was even able to have XSD create a header with "typedef std::string decimal" with that flag, but then I was seeing a bunch of compilation errors (e.g. _clone method not found). I can create a custom class that wraps an std::string attribute, and provide an accessor method that returns the attribute, but I hope there's a simpler way. Thanks, Jesus Herrera From boris at codesynthesis.com Fri Feb 15 09:12:51 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 15 09:28:18 2019 Subject: [xsd-users] XSD C++17 Support In-Reply-To: References: Message-ID: Corey Barnwell writes: > Are there any plans for adding C++17 support to XSD? Seems to be riddled > with auto_ptr usage. >From the NEWS file entry for the 4.0.0 release: * New option, --std, specifies the C++ standard that the generated code should conform to. Valid values are c++98 (default) and c++11. The C++ standard affects various aspects of the generated code that are discussed in more detail in mapping-specific documentation (guides and manuals). Overall, when C++11 is selected, the generated code relies on the move semantics and uses std::unique_ptr instead of deprecated std::auto_ptr. See also the documentation for the --std option in the XSD compiler command line manual (man pages). Though it's probably time to make c++11 the default (or maybe even drop c++98 entirely). > Or is XSD a dead project? I noticed it doesn't seem to have been updated > since 2014. It's a mature project that is in the maintenance mode. But a release is long overdue, that's true. You can try the latest pre-release if you are interested: https://codesynthesis.com/~boris/tmp/xsd/4.1.0.a11/ From boris at codesynthesis.com Fri Feb 15 09:26:06 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 15 09:41:31 2019 Subject: [xsd-users] Unresolved external symbol Wrapper4InputSource In-Reply-To: <034201d4c3be$e66d1ca0$b34755e0$@intellitix.com> References: <034201d4c3be$e66d1ca0$b34755e0$@intellitix.com> Message-ID: jimson.james@intellitix.com writes: > helloworld.obj:-1: error: LNK2019: unresolved external symbol > "__declspec(dllimport) public: __thiscall [...] The "__declspec(dllimport)" part in this symbol tells us that Xerces-C++ headers still think you will be linking the DLL. I think you are having the same issue as described here: https://codesynthesis.com/pipermail/xsd-users/2013-December/004161.html From boris at codesynthesis.com Fri Feb 15 09:35:56 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 15 09:51:21 2019 Subject: [xsd-users] Treat decimal as string In-Reply-To: References: Message-ID: jesus.herrera@toshibagcs.com writes: > Is there a simple way to treat xsd:decimal as strings in C++? > > I played around with the --custom-type flag. I was even able to > have XSD create a header with "typedef std::string decimal" with > that flag, but then I was seeing a bunch of compilation errors > (e.g. _clone method not found). Yes, you are just missing a bit of "glue" code. See the 'double' example in the examples/cxx/tree/custom/ directory. It does pretty much what you are trying to do except for xsd:double (and you would want to map to std::string instead of C++ double). The accompanying README has more details. From gschrad at ll.mit.edu Fri Feb 15 10:23:26 2019 From: gschrad at ll.mit.edu (Schrader, Glenn - 1002 - MITLL) Date: Fri Feb 15 10:39:01 2019 Subject: [xsd-users] XSD C++17 Support In-Reply-To: References: Message-ID: <9b6a6fee6fbc452790375db42023b187@ll.mit.edu> I would argue against dropping c++98. There are some compiler vendors (in the embedded space) with no plans to advance beyond that standard. -----Original Message----- From: xsd-users-bounces@codesynthesis.com On Behalf Of Boris Kolpackov Sent: Friday, February 15, 2019 9:13 AM To: Corey Barnwell Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] XSD C++17 Support Corey Barnwell writes: > Are there any plans for adding C++17 support to XSD? Seems to be > riddled with auto_ptr usage. >From the NEWS file entry for the 4.0.0 release: * New option, --std, specifies the C++ standard that the generated code should conform to. Valid values are c++98 (default) and c++11. The C++ standard affects various aspects of the generated code that are discussed in more detail in mapping-specific documentation (guides and manuals). Overall, when C++11 is selected, the generated code relies on the move semantics and uses std::unique_ptr instead of deprecated std::auto_ptr. See also the documentation for the --std option in the XSD compiler command line manual (man pages). Though it's probably time to make c++11 the default (or maybe even drop c++98 entirely). > Or is XSD a dead project? I noticed it doesn't seem to have been > updated since 2014. It's a mature project that is in the maintenance mode. But a release is long overdue, that's true. You can try the latest pre-release if you are interested: https://codesynthesis.com/~boris/tmp/xsd/4.1.0.a11/ From boris at codesynthesis.com Mon Feb 18 07:14:43 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 18 07:30:18 2019 Subject: [xsd-users] XSD C++17 Support In-Reply-To: <9b6a6fee6fbc452790375db42023b187@ll.mit.edu> References: <9b6a6fee6fbc452790375db42023b187@ll.mit.edu> Message-ID: Schrader, Glenn - 1002 - MITLL writes: > I would argue against dropping c++98. There are some compiler vendors > (in the embedded space) with no plans to advance beyond that standard. Yes, good point. Another alternative is to drop C++98 in the next major release while still maintaining the previous release in the bugfix-only mode. In either case we will make sure to consult the community before making any decisions. From Stefan.Delker at kmweg.de Mon Feb 18 09:47:52 2019 From: Stefan.Delker at kmweg.de (Delker, Stefan) Date: Tue Feb 19 10:10:47 2019 Subject: [xsd-users] BUG in generated code: Custom list type's getDefaultValue() returns twice the number of elements as its defined fixed size In-Reply-To: <7502807853832849A296FE1CAB7A99A10187EC4ECC@MU00VMXCLU02.kmweg.wtlsh.de> References: <3ABB11A9BCAF4548B3B9DF4B2F72A211F7898283@MU00VMXCLU01.kmweg.wtlsh.de> <7502807853832849A296FE1CAB7A99A10187EC4ECC@MU00VMXCLU02.kmweg.wtlsh.de> Message-ID: <3ABB11A9BCAF4548B3B9DF4B2F72A211F78982B6@MU00VMXCLU01.kmweg.wtlsh.de> Dear Sir or Madam, we may have encountered a bug with the generated code based on the following example: XSD: We're using the following generator flags: --generate-serialization --custom-type DISEntityType=/DISEntityType_impl --hxx-epilogue-file Config-custom.inl --generate-default-ctor Our custom type implementation initializes the type by default having 7 elements, to guarantee all data is accessible: class DISEntityType : public DISEntityType_impl { public: DISEntityType () : DISEntityType_impl(DISEntityType_base(7, 0)) {} ... inline uint32_t getKind() const { return uint32_t((*this)[0]); } inline uint32_t getDomain() const { return uint32_t((*this)[1]); } ...(more getter) inline void setKind(uint32_t i) { (*this)[0] = (i & 0xff); } inline void setDomain(uint32_t i) { (*this)[1] = (i & 0xff); } ...(more setter) } While using the generated getEntityTypeDefaultValue(), the returned list contains 14 elements! >From debugging the generated code, the default constructor already initializes the list with 7 elements. The _xsd_entityType_default_value_init () adds seven elements to the default constructed object using (7 times): { ::xml_schema::UnsignedShort tmp (0U); r.push_back (tmp); } This explains the result of 14 elements (which is obviously wrong). Is this actually a bug or are we misusing some feature of XSD? >From our perspective, defining a default to be n times '0' in a type that is defined to have n elements should always result in having exactly n elements. So maybe the default initialization should set its n elements to the given n values instead of adding them to an assumingly empty list? Kind regards [cid:image003.jpg@01D326F2.C2DA1690] Stefan Delker Softwareentwickler | Software engineer Training & Simulation Krauss-Maffei Wegmann GmbH & Co. KG Krauss-Maffei-Strasse 11 D-80997 Munich Fon.: +49 89.8140.4895 stefan.delker@kmweg.de www.kmweg.de Krauss-Maffei Wegmann GmbH & Co. KG Sitz der Gesellschaft ist Muenchen Registergericht: Amtsgericht Muenchen, HRA 72 460 Persoenlich haftende Gesellschafterin: Krauss-Maffei Wegmann Verwaltungs GmbH Sitz der Gesellschaft ist Muenchen Registergericht: Amtsgericht Muenchen, HRB 118952 Geschaeftsfuehrer: Dipl.-Ing. Frank Haun (Vorsitzender), Dipl.-Ing. Ralf Ketzel, Dipl.-Kfm. Horst Rieder, Dipl.-Ing. Michael Ulverich Vorsitzender des Aufsichtsrates: Dipl.-Ing. Dipl.-Wirtsch.-Ing. Axel J. Arendt. -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2295 bytes Desc: image001.jpg Url : https://codesynthesis.com/pipermail/xsd-users/attachments/20190218/7bd306cc/image001.jpg From boris at codesynthesis.com Wed Feb 20 07:55:01 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 20 08:10:45 2019 Subject: [xsd-users] BUG in generated code: Custom list type's getDefaultValue() returns twice the number of elements as its defined fixed size In-Reply-To: <3ABB11A9BCAF4548B3B9DF4B2F72A211F78982B6@MU00VMXCLU01.kmweg.wtlsh.de> References: <3ABB11A9BCAF4548B3B9DF4B2F72A211F7898283@MU00VMXCLU01.kmweg.wtlsh.de> <7502807853832849A296FE1CAB7A99A10187EC4ECC@MU00VMXCLU02.kmweg.wtlsh.de> <3ABB11A9BCAF4548B3B9DF4B2F72A211F78982B6@MU00VMXCLU01.kmweg.wtlsh.de> Message-ID: Delker, Stefan writes: > > > > > > > > > > > > Our custom type implementation initializes the type by default having > 7 elements, to guarantee all data is accessible: > > class DISEntityType : public DISEntityType_impl > { > public: > > DISEntityType () : DISEntityType_impl(DISEntityType_base(7, 0)) {} > > inline uint32_t getKind() const { return uint32_t((*this)[0]); } > > [...] > > } > > From debugging the generated code, the default constructor already > initializes the list with 7 elements. > > The _xsd_entityType_default_value_init () adds seven elements to the > default constructed object using (7 times): > > { > ::xml_schema::UnsignedShort tmp (0U); > r.push_back (tmp); > } > > Is this actually a bug or are we misusing some feature of XSD? I believe the problem is in your mapping of the DISEntityType XML Schema type to the DISEntityType C++ class. It does not reflect what the schema says, which is, "a valid instance of DISEntityType must contain 7 elements" (). It does not say that "a valid instance of type DISEntityType always contains 7 zeroes". In particular, the following would be valid per the schema definition of DISEntityType: In a sense, a more accurate mapping would have been something along these lines: class DISEntityType : public DISEntityType_impl { public: DISEntityType () {} inline uint32_t getKind() const { assert (size () == 7); return uint32_t((*this)[0]); } [...] }; If you want to continue using your current mapping then one (admittedly hackish) way to make it work would be to re-define push_back() (which is pretty useless in your case anyway) along these lines: class DISEntityType : public DISEntityType_impl { public: [...] inline void push_back (unsigned short x) { if (size () == 7) clear (); DISEntityType_impl::push_back (x); } }; From Stefan.Delker at kmweg.de Thu Feb 21 08:43:49 2019 From: Stefan.Delker at kmweg.de (Delker, Stefan) Date: Thu Feb 21 10:06:27 2019 Subject: AW: [xsd-users] BUG in generated code: Custom list type's getDefaultValue() returns twice the number of elements as its defined fixed size In-Reply-To: References: <3ABB11A9BCAF4548B3B9DF4B2F72A211F7898283@MU00VMXCLU01.kmweg.wtlsh.de> <7502807853832849A296FE1CAB7A99A10187EC4ECC@MU00VMXCLU02.kmweg.wtlsh.de> <3ABB11A9BCAF4548B3B9DF4B2F72A211F78982B6@MU00VMXCLU01.kmweg.wtlsh.de> Message-ID: <3ABB11A9BCAF4548B3B9DF4B2F72A211F78CAB25@MU00VMXCLU01.kmweg.wtlsh.de> Thanks a lot for your quick response! I'm not the expert on that topic, but will look into it, if necessary. If the default object should be {0,0,0,0,0,0,0}, maybe any other default definition is irrelevant. Best wishes, Stefan Delker Softwareentwickler | Software engineer Training & Simulation Krauss-Maffei Wegmann GmbH & Co. KG Krauss-Maffei-Strasse 11 D-80997 Munich Fon.: +49 89.8140.4895 stefan.delker@kmweg.de www.kmweg.de -----Urspruengliche Nachricht----- Von: Boris Kolpackov [mailto:boris@codesynthesis.com] Gesendet: Mittwoch, 20. Februar 2019 13:55 An: Delker, Stefan Cc: xsd-users@codesynthesis.com; Haubner, Michael Betreff: Re: [xsd-users] BUG in generated code: Custom list type's getDefaultValue() returns twice the number of elements as its defined fixed size Delker, Stefan writes: > > > > > > > > > > > > Our custom type implementation initializes the type by default having > 7 elements, to guarantee all data is accessible: > > class DISEntityType : public DISEntityType_impl > { > public: > > DISEntityType () : DISEntityType_impl(DISEntityType_base(7, 0)) {} > > inline uint32_t getKind() const { return uint32_t((*this)[0]); } > > [...] > > } > > From debugging the generated code, the default constructor already > initializes the list with 7 elements. > > The _xsd_entityType_default_value_init () adds seven elements to the > default constructed object using (7 times): > > { > ::xml_schema::UnsignedShort tmp (0U); > r.push_back (tmp); > } > > Is this actually a bug or are we misusing some feature of XSD? I believe the problem is in your mapping of the DISEntityType XML Schema type to the DISEntityType C++ class. It does not reflect what the schema says, which is, "a valid instance of DISEntityType must contain 7 elements" (). It does not say that "a valid instance of type DISEntityType always contains 7 zeroes". In particular, the following would be valid per the schema definition of DISEntityType: In a sense, a more accurate mapping would have been something along these lines: class DISEntityType : public DISEntityType_impl { public: DISEntityType () {} inline uint32_t getKind() const { assert (size () == 7); return uint32_t((*this)[0]); } [...] }; If you want to continue using your current mapping then one (admittedly hackish) way to make it work would be to re-define push_back() (which is pretty useless in your case anyway) along these lines: class DISEntityType : public DISEntityType_impl { public: [...] inline void push_back (unsigned short x) { if (size () == 7) clear (); DISEntityType_impl::push_back (x); } }; Krauss-Maffei Wegmann GmbH & Co. KG Sitz der Gesellschaft ist Muenchen Registergericht: Amtsgericht Muenchen, HRA 72 460 Persoenlich haftende Gesellschafterin: Krauss-Maffei Wegmann Verwaltungs GmbH Sitz der Gesellschaft ist Muenchen Registergericht: Amtsgericht Muenchen, HRB 118952 Geschaeftsfuehrer: Dipl.-Ing. Frank Haun (Vorsitzender),Dipl.-Ing. Ralf Ketzel,Dipl.-Kfm. Horst Rieder,Dipl.-Ing. Michael Ulverich Vorsitzender des Aufsichtsrates: Dipl.-Ing. Dipl.-Wirtsch.-Ing. Axel J. Arendt. From Erik.Tempelaar at vanoord.com Thu Feb 28 03:25:30 2019 From: Erik.Tempelaar at vanoord.com (Tempelaar E. (Erik)) Date: Thu Feb 28 08:43:42 2019 Subject: [xsd-users] Segmentation fault in application when parsing large XML with default (8MiB) stack size Message-ID: Dear xsd-users, Our app crashes with segfault when it tries to parse a rather large XML-file (close to the stacksize of 8MiB). As a workaround the stack for the application has been increased. I'd like to get rid of this workaround because I believe it results in large core dumps (the applications uses many threads, unfortunately) My assumption is that the xml-file ends up on the stack somewhere, causing an overflow and corrupting my heap. Does this make sense? Any pointers on how to fix this or gathering more information on the crash? This is what the core dump looks like: vagrant@vagrant-slackware-14-2://release/$ gdb --args ./ //configurations/max_udp/ GNU gdb (GDB) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i586-slackware-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./...done. (gdb) run Starting program: //release// //configurations/max_udp/ [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". [New Thread 0xb7c10b40 (LWP 3612)] [2019-02-28 06:34:12.972] [INFO ] worker thread RemoteLogging started, PID: 3612 [New Thread 0xb76ffb40 (LWP 3616)] [2019-02-28 06:34:13.350] [INFO ] configuration loaded from: //large_file.xml Thread 1 "" received signal SIGSEGV, Segmentation fault. 0xb7c91418 in _int_malloc () from /lib/libc.so.6 (gdb) info frame Stack level 0, frame at 0xbfc00070: eip = 0xb7c91418 in _int_malloc; saved eip = 0xb7c941d0 called by frame at 0xbfc000a0 Arglist at 0xbfbfffc4, args: Locals at 0xbfbfffc4, Previous frame's sp is 0xbfc00070 Saved registers: ebx at 0xbfc0005c, ebp at 0xbfc00068, esi at 0xbfc00060, edi at 0xbfc00064, eip at 0xbfc0006c (gdb) info stack #0 0xb7c91418 in _int_malloc () from /lib/libc.so.6 #1 0xb7c941d0 in malloc () from /lib/libc.so.6 #2 0xb7eac63b in operator new(unsigned int) () from /usr/lib/libstdc++.so.6 #3 0x0818f010 in xercesc_3_2::MemoryManagerImpl::allocate(unsigned int) () #4 0x0821f905 in xercesc_3_2::RegularExpression::Context::Context(xercesc_3_2::RegularExpression::Context*) () #5 0x08224055 in xercesc_3_2::RegularExpression::matchUnion(xercesc_3_2::RegularExpression::Context*, xercesc_3_2::Op const*, unsigned int) const () #6 0x08221097 in xercesc_3_2::RegularExpression::match(xercesc_3_2::RegularExpression::Context*, xercesc_3_2::Op const*, unsigned int) const () #7 0x08224090 in xercesc_3_2::RegularExpression::matchUnion(xercesc_3_2::RegularExpression::Context*, xercesc_3_2::Op const*, unsigned int) const () #8 0x08221097 in xercesc_3_2::RegularExpression::match(xercesc_3_2::RegularExpression::Context*, xercesc_3_2::Op const*, unsigned int) const () #9 0x08224090 in xercesc_3_2::RegularExpression::matchUnion(xercesc_3_2::RegularExpression::Context*, xercesc_3_2::Op const*, unsigned int) const () #10 0x08221097 in xercesc_3_2::RegularExpression::match(xercesc_3_2::RegularExpression::Context*, xercesc_3_2::Op const*, unsigned int) const () #11 0x08224090 in xercesc_3_2::RegularExpression::matchUnion(xercesc_3_2::RegularExpression::Context*, xercesc_3_2::Op const*, unsigned int) const () #12 0x08221097 in xercesc_3_2::RegularExpression::match(xercesc_3_2::RegularExpression::Context*, xercesc_3_2::Op const*, unsigned int) const () ... this continues ... #32725 0x0822186f in xercesc_3_2::RegularExpression::matches(char16_t const*, unsigned int, unsigned int, xercesc_3_2::Match*, xercesc_3_2::MemoryManager*) const () #32726 0x082220fb in xercesc_3_2::RegularExpression::matches(char16_t const*, xercesc_3_2::MemoryManager*) const () #32727 0x08288791 in xercesc_3_2::AbstractStringValidator::checkContent(char16_t const*, xercesc_3_2::ValidationContext*, bool, xercesc_3_2::MemoryManager*) () #32728 0x082874ff in xercesc_3_2::AbstractStringValidator::validate(char16_t const*, xercesc_3_2::ValidationContext*, xercesc_3_2::MemoryManager*) () #32729 0x0829915d in xercesc_3_2::SchemaValidator::checkContent(xercesc_3_2::XMLElementDecl*, xercesc_3_2::QName**, unsigned int, unsigned int*) () #32730 0x082c944b in xercesc_3_2::IGXMLScanner::scanEndTag(bool&) () #32731 0x082d021c in xercesc_3_2::IGXMLScanner::scanContent() () #32732 0x082d03e8 in xercesc_3_2::IGXMLScanner::scanDocument(xercesc_3_2::InputSource const&) () #32733 0x0819e367 in xercesc_3_2::XMLScanner::scanDocument(char16_t const*) () #32734 0x08270b0e in xercesc_3_2::AbstractDOMParser::parse(char16_t const*) () #32735 0x081af99c in xercesc_3_2::DOMLSParserImpl::parseURI(char16_t const*) () #32736 0x0811066d in xsd::cxx::xml::dom::parse (uri=..., eh=..., prop=..., flags=0) at ../../../resources/include/xsd/cxx/xml/dom/parsing-source.txx:367 #32737 0x0812a44f in xsd::cxx::xml::dom::parse (flags=, prop=..., eh=..., uri=...) at ../../../resources/include/xsd/cxx/xml/dom/parsing-source.txx:244 #32738 DeviceConfig (u=..., f=..., p=...) at generated/device_config.cpp:6955 #32739 0x08052201 in Server::AppendDeviceConfiguration (this=0x84bb5f0, xml_path=...) at ../../modules/common/Server.cpp:190 #32740 0x080544c3 in Server::ReadConfiguration (this=0x84bb5f0) at ../../modules/common/Server.cpp:343 #32741 0x0804e39f in Application (path=...) at ../../modules/common/main.cpp:181 #32742 main (argc=2, argv=0xbffff384) at ../../modules/common/main.cpp:441 XSD 4.0.0 with Xerces-c 3.2 Xerces-c Windows / Msys2 / mingw32 ../xerces-c-3.2.0/configure --prefix=/home/data/xerces --build=i686-w64-mingw32 --disable-shared --disable-network --disable-sse2 CFLAGS="-std=gnu11 -O3 -mno-ms-bitfields -mthreads" CXXFLAGS="-std=gnu++11 -O3 -mno-ms-bitfields -mthreads" Linux (Slackware) ../xerces-c-3.2.0/configure --prefix=/home/data/xerces --disable-shared --disable-network --disable-sse2 CFLAGS="-std=gnu11 -O3 -mno-ms-bitfields" CXXFLAGS="-std=gnu++11 -O3 -mno-ms-bitfields" XSD Windows / Msys2 / mingw32 make CFLAGS="-std=gnu11 -O3 -mno-ms-bitfields" CXXFLAGS="-std=gnu++11 -O3 -mno-ms-bitfields -I../../../resources/include" LDFLAGS="-s -static -static-libgcc -static-libstdc++ -L../../../resources/lib/msys2/xerces-c" Linux (Slackware) make CFLAGS="-std=gnu11 -O3 -mno-ms-bitfields -pthread" CXXFLAGS="-std=gnu++11 -O3 -mno-ms-bitfields -pthread -I../../../resources/include" LDFLAGS="-s -L../../../resources/lib/linux/xerces-c" I appreciate any advice. Kind regards, Erik Disclaimer: This mail transmission and any attached files are confidential and are intended for the addressee only. If you are not the person or organization to whom it is addressed, you must not copy, disclose, distribute or take any action in reliance upon it. If you have received this message in error, please contact the sender by email and delete all copies of this message and all copies of any attached files.