[PATCH 0/2] libdom: fix two more libxml parser segfaults
by Michael Orlitzky
The libsvgtiny test suite exposes two segfaults in libdom's libxml2
parser. The first I'm somewhat confident in: linking dom/xml nodes
can fail (or never happen), and if we encounter an unlinked node,
something is wrong. Reasonable enough.
The second was easy to fix, but I'm not as sure that the fix is
correct. There's a branch where we jump to parent->children if we
can't find an earlier element node, and in at least one case, there
are no such children. Should there be? Adding a NULL check avoids a
segfault, but maybe we should notice the problem sooner.
Michael Orlitzky (2):
bindings/xml/libxml_xmlparser.c: fix segfault due to unlinked parent
bindings/xml/libxml_xmlparser.c: fix segfault on malformed document
bindings/xml/libxml_xmlparser.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--
2.41.0
2 months, 1 week
[PATCH] makefiles/Makefile.top: dependencies for PRE_ and POST_TARGETS
by Michael Orlitzky
The PRE_TARGETS and POST_TARGETS are supposed to be built before and
after $(OBJECTS), respectively -- at least according to the comments
in Makefile.top:
# List of targets to run before building $(OBJECT)
PRE_TARGETS :=
# List of targets to run after building $(OBJECT)
POST_TARGETS :=
The default target however builds them at the same time as $(OUTPUT),
# Default target
all: $(PRE_TARGETS) $(OUTPUT) $(POST_TARGETS)
where $(OUTPUT) basically just builds $(OBJECTS):
$(OUTPUT): $(BUILDDIR)/stamp $(OBJECTS)
...
As a result, there is a race condition when $(OBJECTS) truly requires
$(PRE_TARGETS), because they may be built at the same time. The same
problem arises the other way around with $(POST_TARGETS). As a
demonstration, one can try to build the libsvgtiny shared library
directly (note: the details are platform-dependent),
$ BD=build-x86_64-pc-linux-gnu-x86_64-pc-linux-gnu-release-lib-shared
$ make COMPONENT_TYPE=lib-shared "${BD}/libsvgtiny.so.0.1.7"
COMPILE: src/svgtiny.c
...
src/svgtiny.c:24:10: fatal error: autogenerated_colors.c: No such file or directory
24 | #include "autogenerated_colors.c"
| ^~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
This is because $(PRE_TARGETS) is not satisfied. In practice, this
condition seems hard to hit unintentionally, but it can happen if you
are building in parallel and extemely unlucky. A user discovered it in
Gentoo bug 711200.
The fix simply adds the stated dependencies on $(OBJECTS) and
$(POST_TARGETS) to guarantee the correct order.
---
makefiles/Makefile.top | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/makefiles/Makefile.top b/makefiles/Makefile.top
index caac166..dafdfaa 100644
--- a/makefiles/Makefile.top
+++ b/makefiles/Makefile.top
@@ -176,6 +176,11 @@ OBJECTS := $(addprefix $(BUILDDIR)/,$(filter %.o, \
$(subst /,_,$(subst .cmhg,.o,$(SOURCES))) \
$(subst /,_,$(subst .s,.o,$(SOURCES)))))
+# Ensure that PRE_TARGETS are built before OBJECTS, and POST_TARGETS
+# after them.
+$(OBJECTS): $(PRE_TARGETS)
+$(POST_TARGETS): $(OBJECTS)
+
bin_for_test = $(addprefix $(BUILDDIR)/,$(firstword $(subst :, ,$(ITEM))))
TEST_BINARIES := $(foreach ITEM,$(TEST_ITEMS),$(bin_for_test))
--
2.41.0
2 months, 1 week
[PATCH] makefiles: support building shared libs on Darwin
by Caleb Xu
On Darwin (macOS), the flags needed to create a shared
library are different. Moreover, the extension is .dylib
and the version portion of the soname is inserted between
the library name and the libext, e.g. lifoo.1.2.3.dylib.
Signed-off-by: Caleb Xu <calebcenter(a)live.com>
---
makefiles/Makefile.clang | 7 ++++++-
makefiles/Makefile.gcc | 6 +++++-
makefiles/Makefile.tools | 6 +++++-
makefiles/Makefile.top | 14 +++++++++++---
4 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/makefiles/Makefile.clang b/makefiles/Makefile.clang
index 50f8a82..bcd14e3 100644
--- a/makefiles/Makefile.clang
+++ b/makefiles/Makefile.clang
@@ -21,7 +21,12 @@ CXXSHR := -fPIC
LDDBG := -g
# Reevaluation is required here
-LDSHR = -shared -Wl,-soname,$(SONAME)
+ifeq ($(findstring darwin,$(HOST)),darwin)
+ LDSHR = -dynamiclib -install_name $(SONAME)
+else
+ LDSHR = -shared -Wl,-soname,$(SONAME)
+endif
+
ARFLG := cru
diff --git a/makefiles/Makefile.gcc b/makefiles/Makefile.gcc
index b5119ac..4a9dff7 100644
--- a/makefiles/Makefile.gcc
+++ b/makefiles/Makefile.gcc
@@ -20,7 +20,11 @@ CXXSHR := -fPIC
LDDBG := -g
# Reevaluation is required here
-LDSHR = -shared -Wl,-soname,$(SONAME)
+ifeq ($(findstring darwin,$(HOST)),darwin)
+ LDSHR = -dynamiclib -install_name $(SONAME)
+else
+ LDSHR = -shared -Wl,-soname,$(SONAME)
+endif
ARFLG := cru
diff --git a/makefiles/Makefile.tools b/makefiles/Makefile.tools
index 112e7f8..e5504e7 100644
--- a/makefiles/Makefile.tools
+++ b/makefiles/Makefile.tools
@@ -478,7 +478,11 @@ LDFLAGS := $(LDFLAGS) $(OPTLDFLAGS)
ifeq ($(COMPONENT_TYPE),lib-static)
LIBEXT ?= .a
else
- LIBEXT ?= .so
+ ifeq ($(findstring darwin,$(HOST)),darwin)
+ LIBEXT ?= .dylib
+ else
+ LIBEXT ?= .so
+ endif
endif
# If we're building a shared library, modify the flags appropriately
diff --git a/makefiles/Makefile.top b/makefiles/Makefile.top
index caac166..0b0fe22 100644
--- a/makefiles/Makefile.top
+++ b/makefiles/Makefile.top
@@ -189,9 +189,17 @@ endif
# Determine the output filename
ifeq ($(findstring lib,$(COMPONENT_TYPE)),lib)
ifeq ($(findstring lib-shared,$(COMPONENT_TYPE)),lib-shared)
- SHAREDLIBNAME := lib$(COMPONENT)$(LIBEXT)
- SONAME := $(SHAREDLIBNAME).$(major-version)
- OUTPUT := $(BUILDDIR)/$(SHAREDLIBNAME).$(COMPONENT_VERSION)
+ ifeq ($(findstring darwin,$(HOST)),darwin)
+ # In macOS, shared lib filenames are of the form libfoo.dylib,
+ # libfoo.1.dylib, or libfoo.1.2.3.dylib
+ SONAME := lib$(COMPONENT).$(major-version)$(LIBEXT)
+ SHAREDLIBNAME := lib$(COMPONENT)$(LIBEXT)
+ OUTPUT := $(BUILDDIR)/lib$(COMPONENT).$(COMPONENT_VERSION)$(LIBEXT)
+ else
+ SHAREDLIBNAME := lib$(COMPONENT)$(LIBEXT)
+ SONAME := $(SHAREDLIBNAME).$(major-version)
+ OUTPUT := $(BUILDDIR)/$(SHAREDLIBNAME).$(COMPONENT_VERSION)
+ endif
else
OUTPUT := $(BUILDDIR)/lib$(COMPONENT)$(LIBEXT)
endif
--
2.41.0
2 months, 2 weeks
"error: ‘t.data.character.ptr’ may be used uninitialized " when building hubbub with gcc 11
by Andy Tai
Hi, I found from GNU Guix's build check that when building with gcc 11,
building hubbub would fail when building tests with errors like
COMPILE: test/tokeniser2.c
COMPILE: test/tokeniser3.c
COMPILE: test/tree.c
COMPILE: test/tree2.c
COMPILE: test/tree-buf.c
test/tokeniser2.c: In function ‘token_handler’:
test/tokeniser2.c:444:46: error: ‘t.data.character.ptr’ may be used
uninitialized [-Werror=maybe-uninitialized]
444 | t.data.character.ptr += len;
| ^~
test/tokeniser2.c:441:38: note: ‘t’ declared here
441 | hubbub_token t;
| ^
test/tokeniser2.c:445:46: error: ‘t.data.character.len’ may be used
uninitialized [-Werror=maybe-uninitialized]
445 | t.data.character.len -= len;
| ^~
...
I briefly took a look of the test source code in question and the
hubbub_token structs seem not explicitly initialized. Is this a real
warning from gcc of possibly uninitialized variable which can cause
the build to fail if allow warnings are treated as errors by gcc
during build (a common practice)? Thanks if maintainer can take a
look.
relevant bug entry and complete bug logs:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63526
2 months, 2 weeks
[PATCH 0/1] libdom: handle empty document with libxml
by Michael Orlitzky
I encountered a segfault while trying to parse an empty file with
libsvgtiny that I traced back to libdom. It looks like a missing NULL
check is to blame. I have yet to (figure out how to) run the libdom
test suite however, so caveat emptor.
Michael Orlitzky (1):
bindings/xml/libxml_xmlparser.c: handle an empty document
bindings/xml/libxml_xmlparser.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--
2.39.3
3 months, 3 weeks
[PATCH 0/4] fix the example program
by Michael Orlitzky
A few miscellaneous changes that I needed to get the example program
working again.
Michael Orlitzky (4):
README: update LIBXML -> LIBDOM
examples/svgtiny_display_x11.c: update LIBXML -> LIBDOM
examples/svgtiny_display_x11.c: add missing stdlib.h include
examples/svgtiny_display_x11.c: include the system copy of svgtiny.h
README | 2 +-
examples/svgtiny_display_x11.c | 7 ++++---
2 files changed, 5 insertions(+), 4 deletions(-)
--
2.39.3
3 months, 3 weeks