Re: [xml] interaction between xmlSetGenericErrorFunc and xmlSetStructuredErrorFunc can crash (draft patch available)

[Daniel Veillard <veillard redhat com>]

On Wed, Jul 29, 2009 at 08:16:35PM -0700, Wang Lam wrote:
> On 07/29/2009 03:03 AM, Daniel Veillard wrote:
>
> > On Mon, Jul 27, 2009 at 08:05:37PM -0700, Wang Lam wrote:
> :
> > > (b) Worse than being invoked, though, the default xmlGenericError
> > >     crashed (instead of, say, printing to stderr).
> > >
> > >     From what I see, xmlGenericErrorFunc and xmlStructuredErrorFunc
> > >     share a single xmlGenericErrorContext; setting one function
> > >     overwrites the other function's context.  In the above example
> :
> >   yes, I agree with the diagnostic, I came up to the same conclusion,
> > this need fixing !
> >
> > >     With a patch to create xmlStructuredErrorContext, I get a different
> > >     result from the above example code:
> >
> >   yes, I think I know what you patch does, add the new variable in
> >   globals.c, initialize it properly, and use it for the strcutured
> >   error paths in error.c
> :
> >   yes please or just reply with the attached patch, I expect to do
> >   libxml2 maintainace today and tomorrow !
>
> Please find my (slightly edited) `git diff` output attached.

  Just to tell I started looking at it, thanks a lot. But I may go to
the simplest patch and not try to regenerate again global variables.
The trend is really to try to get rid of them, rather than add more as
it is a pain for various reasons.

> Just a warning--the diff also contains a few side-effect diffs from the
> implementation that you may want to review or edit:
>
> * It seems that globals were intended to go into global.data, then fed
>   through a code-generator (build_glob.py) to generate globals.{h,c}.
>   Unfortunately, the output of global.data + build_glob.py and the
>   checked-in snapshot of the globals.* output files seem to have
>   diverged at some point.
>
>   I tried to reconcile most of the differences, but a few remain (mainly
>   the way declarations are automatically written in globals.h, and some
>   use of #ifdef LIBXML_SAX1_ENABLED in globals.c).
>
> * I didn't check the generated HTML output at all, though there seemed
>   to be a few changes there generated from an underlying diff in
>   libxml2-api.xml.
>
> * I removed a few files' changes where the changes didn't seem directly
>   related to xmlSetStructuredErrorFunc at all (namely: config.h.in,
>   xmlcatalog.1, and xmllint.1).  I'd be happy to mail these diffs to you
>   if you'd like; they look like they're just artifacts of a slightly
>   different build environment, though.
>
> In short, my cursory understanding of the source tree suggests that
> libxml2-api.xml, error.c, global.data, and globals.* (above their
> respective autogeneration-starts-here lines) are the only diffs that
> are "supposed" to matter, but a few more popped out anyway...

  yes

> I hope this diff is helpful.  If you encounter any trouble with it,
> please drop me a line so that I can see what I can figure out.

  No that was fine, I will probably go for the simplestb route though !

   thanks again !

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel veillard com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/