Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Core dump when compile with gcc 10 #90

Open
softrobotYCLi opened this issue Nov 30, 2023 · 3 comments
Open

Core dump when compile with gcc 10 #90

softrobotYCLi opened this issue Nov 30, 2023 · 3 comments

Comments

@softrobotYCLi
Copy link

Hi all, i meet a segment fault when compiling libxo with gcc 10.
we can use these following commands to reproduce the problem:

yum install libtool git make
cp /usr/include/linux/sysctl.h /usr/include/sys/sysctl.h

git clone http://github.com/Juniper/libxo.git

sh bin/setup.sh
cd build
../configure
make
make install
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/


[root@localhost build]# cat test.c
#include <libxo/xo.h>

int main(int argc, char *argv[])
{
   xo_emit("{d:/%-*.*s}{etk:name}{eq:flags/0x%x}", 0, 0, NULL, NULL, 0);
}

gcc test.c -g -L /usr/local/lib/ -lxo -I /usr/local/include/libxo -o test
./test
Segmentation fault (core dumped)

env info:

[lyc@localhost:lib]$ rpm -q glibc
glibc-2.34-124.oe2203sp2.aarch64
[lyc@localhost:lib]$ rpm -q kernel
kernel-5.10.0-153.12.0.92.oe2203sp2.aarch64
[lyc@localhost:lib]$ uname -a
Linux localhost 5.10.0-153.12.0.92.oe2203sp2.aarch64 #1 SMP Wed Jun 28 23:18:48 CST 2023 aarch64 aarch64 aarch64 GNU/Linux
[lyc@localhost:lib]$ gcc -v
using built-in specs。
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-linux-gnu/10.3.1/lto-wrapper
target:aarch64-linux-gnu
configure with:../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,fortran,objc,obj-c++,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl --without-cloog --enable-gnu-indirect-function --build=aarch64-linux-gnu --with-stage1-ldflags=' -Wl,-z,relro,-z,now' --with-boot-ldflags=' -Wl,-z,relro,-z,now' --disable-bootstrap --with-multilib-list=lp64 --enable-bolt
thread model:posix
Supported LTO compression algorithms: zlib
@pinskia
Copy link

pinskia commented Dec 1, 2023

This is a bug in libxo in the assumption about name after a call to memcpy, this patch fixes the issue for me:

diff --git a/libxo/libxo.c b/libxo/libxo.c
index 916a111..ea71723 100644
--- a/libxo/libxo.c
+++ b/libxo/libxo.c
@@ -4300,7 +4300,8 @@ xo_format_value (xo_handle_t *xop, const char *name, ssize_t nlen,
        if ((xsp->xs_flags & (XSF_EMIT | XSF_EMIT_KEY))
            || !(xsp->xs_flags & XSF_EMIT_LEAF_LIST)) {
            char nbuf[nlen + 1];
-           memcpy(nbuf, name, nlen);
+            if (name)
+             memcpy(nbuf, name, nlen);
            nbuf[nlen] = '\0';

            ssize_t rc = xo_transition(xop, 0, nbuf, XSS_EMIT_LEAF_LIST);
@@ -4324,7 +4325,8 @@ xo_format_value (xo_handle_t *xop, const char *name, ssize_t nlen,

        } else if (!(xsp->xs_flags & XSF_EMIT_KEY)) {
            char nbuf[nlen + 1];
-           memcpy(nbuf, name, nlen);
+            if (name)
+             memcpy(nbuf, name, nlen);
            nbuf[nlen] = '\0';

            ssize_t rc = xo_transition(xop, 0, nbuf, XSS_EMIT);
@@ -4342,7 +4344,8 @@ xo_format_value (xo_handle_t *xop, const char *name, ssize_t nlen,
        if ((xsp->xs_flags & XSF_EMIT_LEAF_LIST)
            || !(xsp->xs_flags & XSF_EMIT)) {
            char nbuf[nlen + 1];
-           memcpy(nbuf, name, nlen);
+            if (name)
+             memcpy(nbuf, name, nlen);
            nbuf[nlen] = '\0';

            ssize_t rc = xo_transition(xop, 0, nbuf, XSS_EMIT);

@softrobotYCLi
Copy link
Author

Thank you for your reply, i will check and test the patch.

@softrobotYCLi
Copy link
Author

The problem has been fixed. Who will submit a PR to completely close the problem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants