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 736077 - Recursive templates may cause stack overflow
Recursive templates may cause stack overflow
Status: RESOLVED OBSOLETE
Product: libxslt
Classification: Platform
Component: general
unspecified
Other Linux
: Normal critical
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
: 751764 778769 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-09-04 20:24 UTC by wzssyqa
Modified: 2021-07-05 11:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
example for bus error (553.24 KB, text/xml)
2014-09-04 20:24 UTC, wzssyqa
Details
example for bus error 1 (2.88 KB, text/plain)
2014-09-04 20:26 UTC, wzssyqa
Details
verbose log for xsltproc bus error (1.00 MB, application/octet-stream)
2014-09-04 20:28 UTC, wzssyqa
Details
gdb backtrace of error (12.66 KB, application/octet-stream)
2014-09-11 02:49 UTC, wzssyqa
Details

Description wzssyqa 2014-09-04 20:24:12 UTC
When process some files, xsltproc met bus error on some architecture, 
include armhf, mips64el, i386 etc.

This problem make lots of packages ftbfs on Debian.

When try to use gdb or valgrind, we cannot get crash.

With '--verbose', we can get crash, wish it be helpful.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750593 for more details
Comment 1 wzssyqa 2014-09-04 20:24:55 UTC
Created attachment 285410 [details]
example for bus error
Comment 2 wzssyqa 2014-09-04 20:26:36 UTC
Created attachment 285411 [details]
example for bus error 1
Comment 3 wzssyqa 2014-09-04 20:28:09 UTC
Created attachment 285412 [details]
verbose log for xsltproc bus error
Comment 4 wzssyqa 2014-09-11 02:49:54 UTC
Created attachment 285876 [details]
gdb backtrace of error
Comment 5 Nick Wellnhofer 2014-09-28 10:13:01 UTC
Can you please

- Use gzip if you attach compressed files.
- Try to reduce the problem to a short, self-contained test case.
- If that's not possible, tell us at least which version of docbook.xsl produced the error.
Comment 6 Nick Wellnhofer 2014-10-04 10:35:28 UTC
Hmm, the call trace is 5381 functions deep and definitely looks like a stack overflow from a recursive XSLT template. Your options are:

- Increase stack size.
- Isolate the recursive template that causes the error and ask the docbook-xsl maintainers whether they can replace it with a non-recursive version.
Comment 7 Nick Wellnhofer 2015-08-08 17:18:36 UTC
*** Bug 751764 has been marked as a duplicate of this bug. ***
Comment 9 Douglas Bagnall 2015-08-09 06:05:44 UTC
See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1471029

A few versions of the linux kernel around 3.19 and 4.0 laid out the memory in
PIE executables on 32 bit machines in a way that gives the stack and heap very little room and they bang into each other.
Comment 10 John Paul Adrian Glaubitz 2015-12-21 17:34:03 UTC
(In reply to Douglas Bagnall from comment #9)
> A few versions of the linux kernel around 3.19 and 4.0 laid out the memory in
> PIE executables on 32 bit machines in a way that gives the stack and heap
> very little room and they bang into each other.

Well, it doesn't seem to be limited to 32-bit architectures. We're seeing this issue on sparc64 as well and apparently also on mips64el (although I don't know whether it has been fixed on this architecture already).

Adrian
Comment 11 John Paul Adrian Glaubitz 2015-12-31 12:12:14 UTC
(In reply to Douglas Bagnall from comment #9)
> A few versions of the linux kernel around 3.19 and 4.0 laid out the memory in
> PIE executables on 32 bit machines in a way that gives the stack and heap
> very little room and they bang into each other.

Even kernel 4.3.3 does not make a difference on sparc64, unfortunately:

> https://people.debian.org/~glaubitz/systemd_228-2_sparc64-20151231-1419.build

So this is apparently a bug in xsltproc. It shouldn't segfault under any circumstances when churning input files.

Adrian
Comment 12 John Paul Adrian Glaubitz 2016-01-03 10:31:23 UTC
Hello!

Is there any chances that xsltproc is somehow improved? I don't agree that this isn't a bug in xsltproc as the application randomly segfaults on various platforms:

> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1471029
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203250
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195044
> https://forums.gentoo.org/viewtopic-t-248184-start-0.html
> https://trac.macports.org/ticket/24060

It's really starting to become annoying as it hinders the porting efforts for Debian on sparc64 as well randomly lets packages to build from source on platforms like FreeBSD.

Adrian
Comment 13 Nick Wellnhofer 2016-01-03 13:29:50 UTC
The root cause of the issue is excessive stack usage by recursive templates. A proper fix would require tail call optimization in libxslt which is unlikely to be implemented.
Comment 14 Nick Wellnhofer 2017-02-16 22:11:28 UTC
*** Bug 778769 has been marked as a duplicate of this bug. ***
Comment 15 GNOME Infrastructure Team 2021-07-05 11:00:17 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.