After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 349645 - libxslt creates a new dict in xsltNewTransformContext that ends up in the result document
libxslt creates a new dict in xsltNewTransformContext that ends up in the res...
Status: RESOLVED OBSOLETE
Product: libxslt
Classification: Platform
Component: general
1.1.x
Other All
: Normal enhancement
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2006-08-02 09:36 UTC by Stefan Behnel
Modified: 2021-07-05 10:59 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stefan Behnel 2006-08-02 09:36:21 UTC
Please describe the problem:
xsltNewTransformContext contains this code:
    cur->dict = xmlDictCreateSub(style->dict);
This creates a new subdictionary, that is then used during the transformation and copied into the result document in xsltApplyStylesheetInternal.

The problem is that this dictionary cannot be controlled by the user. In lxml, we use a global dictionary for everything that we store in the parser contexts etc. That way, it is shared by all documents *except* those created by XSLT. So, when subtrees are moved between trees, we end up with strings from different dictionaries in one tree. If the source tree is freed before the destination tree, the program can crash for XSLT generated subtrees, while it would work nicely for everything else.

To solve this problem, I would prefer having libxslt either a) use the dictionary of the source document or the one of the stylesheet *directly* for transformations or b) provide a way to set the dictionary used in the transform context by hand.

While we could replace the transform dictionary directly after creating the context, it has already been used before we get our hands on it, so we would have to move all of its entries to the global dictionary first. It would be much easier if libxslt did not enforce the creation of a new dictionary.


Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Daniel Veillard 2006-08-02 11:26:16 UTC
a) is impossible ! source document and stylesheet document are immutable
when doing a transformation, their dict is part of their structure. This
would crash in many apps using libxslt for parallel transformations
or using memory pools different for stylesheets and generated documents.

Using dictionaries for the generated document is a key feature for speed
and space of transformation.
Generating a derived dictionnary which is mutable based on an immutable
existing dictionnary is a key requirement of correct processing of libxslt
to allow parallel processing, no locking, and memory pools.
Based on those 2 points the behaviour you describe is definitely a feature,
not a bug !

For b) propose an API (and patches if possible), but do that on the list
please so that peer review occurs. That should be requalified as a request
for enhancement

Daniel
Comment 2 Stefan Behnel 2006-08-06 19:00:41 UTC
Ok, I noticed that the same approach as we use for the parser dict works for libxslt. There is a comment in transform.c/xsltNewTransformContext() saying:

   /*
    * setup of the dictionnary must be done early as some of the
    * processing later like key handling may need it.
    */

However, this is clearly misleading as the dict is used nowhere that I can see in the xsltNewTransformContext function or in any of the functions it calls. So it is currently safe to replace the dict after the function returned the newly created context.

Would it be possible to move the dict creation to the end of the function and add a comment that it must not be used any earlier as the user may replace it after having created the context? This would remove the need for an extra API and solve the current problem. Since I consider this a rarely encountered problem, such a fix would be less intrusive than a new API, while allowing the users who require this functionality to use it in a safe way.

Stefan
Comment 3 Daniel Veillard 2006-08-06 20:04:31 UTC
Hum, again, subscribe to the mailing-list, make the suggestion (and possibly
add a patch as an attachment), this will allow the peer review that bugzilla
does not offer, and verify that make tests still passes with that change.
Then you pretty sure upstream code will change quickly, otherwise it will
wait until someone have the time to process that request for enhancement,
and feel compelled to implement it. If you want to go forward quickly follow
my instructions, see also end of comment #1

Daniel
Comment 4 GNOME Infrastructure Team 2021-07-05 10:59:31 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/libxslt/-/issues/

Thank you for your understanding and your help.