A list for the developers of CellML tools
Text archives Help
- From: ak.miller at auckland.ac.nz (Andrew Miller)
- Subject: [cellml-dev] [libsbml-team] Changing state in libxml
- Date: Wed, 02 Mar 2011 14:44:05 +1300
On 19/02/11 14:12, Lucian Smith wrote:
> These are all things that *I* can do, and would work for my own
> self-compiled programs. But Antimony itself is supposed to be a library,
> to be compiled by others for use in their own programs. Ideally, it would
> just drop in to whatever system they were already using libsbml or the
> cellml api for, and would bring it only the new dependencies. But this
> particular issue, if left unresolved, makes that impossible, and requires
> particular versions of its dependent libraries.
>
> If this turns out to literally be insoluable, I will have to just tell
> people 'either don't use libsbml compiled with libxml, or don't use cellml
> support at all', but sheesh. I would think there is a real solution out
> there, and not merely a series of complicated workarounds. Since libsbml
> manages to use libxml without spoiling it for use in libcellml, I would
> think the reverse could be accomplished as well.
I'm wondering if it is the use of xmlSetStructuredErrorFunc that causes
problems; we certainly could remove any set error handlers.
As a workaround, does calling xmlSetStructuredErrorFunc(NULL, NULL)
between using the CellML API implementation and libSBML solve the problem?
Best wishes,
Andrew
>
> -Lucian
>
> * Frank T. Bergmann<fbergman at caltech.edu> [2011-02-19 00:49] writes:
>> The next thing to try then is to use static linking of libxml2 (perhaps
>> using the CMake project files) for LibSBML if you really need libXML2 at
>> this point.
>>
>> Frank
>>
>> On Feb 18, 2011, at 4:40 PM, Lucian Smith wrote:
>>
>>> And indeed, configuring lisbml with expat instead makes the problem go
>>> away, as expected.
>>>
>>> This is a reasonable workaround for now, but I would still like to find a
>>> more permanent solution.
>>>
>>> -Lucian
>>>
>>> * Frank T. Bergmann<fbergman at caltech.edu> [2011-02-19 00:18] writes:
>>>> Perhaps you could try to configure libsbml to work with expat, or
>>>> xerces-c.
>>>> That will help you to narrow down your suspicion. If the crash persists
>>>> then
>>>> you know that it is not due to both libraries using libxml.
>>>>
>>>> Cheers
>>>> Frank
>>>>
>>>>> -----Original Message-----
>>>>> From: libsbml-team-bounces at caltech.edu [mailto:libsbml-team-
>>>>> bounces at caltech.edu] On Behalf Of Lucian Smith
>>>>> Sent: Friday, February 18, 2011 4:12 PM
>>>>> To: A list for the developers of CellML tools
>>>>> Cc: libSBML Team
>>>>> Subject: [libsbml-team] Changing state in libxml
>>>>>
>>>>> When trying to code up a translator which would convert between CellML,
>>>>> Antimony, and SBML, I ran into the following problem.
>>>>>
>>>>> Right now, I have libsbml configured to use libxml, the same XML parser
>>>> that
>>>>> CellML uses. I can read a document in with libsbml, and everything is
>>>> fine. I
>>>>> can then read a document with the CellML API, and everything is fine.
>>>>> However, if I then read that same document with libsbml, I get a
>>>>> segfault
>>>>> error, and if I run it though valgrind, I'm actually getting an invalid
>>>> read.
>>>>>
>>>>> Attached is a smallish program that demonstrates this issue. It seems
>>>>> to
>>>> me
>>>>> that CellML is changing the state of libxml in some way, and this messes
>>>> up the
>>>>> subsequent libsbml call, causing the segfault.
>>>>>
>>>>> So my question is: how does CellML change the state of libxml, and how
>>>>> do
>>>> I
>>>>> undo this? Or is there something else going on?
>>>>>
>>>>> -Lucian
>>>>
>>>>
>>
> _______________________________________________
> cellml-tools-developers mailing list
> cellml-tools-developers at cellml.org
> http://lists.cellml.org/mailman/listinfo/cellml-tools-developers
- [cellml-dev] [libsbml-team] Changing state in libxml, Andrew Miller, 03/02/2011
- [cellml-dev] [libsbml-team] Changing state in libxml, Lucian Smith, 03/04/2011
Archive powered by MHonArc 2.6.18.
