[Bug ipa/112783] New: core dump on libxo when function is inlined

[Bug ipa/112783] New: core dump on libxo when function is inlined

[yancheng.li at foxmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783

            Bug ID: 112783
           Summary: core dump on libxo when function is inlined
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yancheng.li at foxmail dot com
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hi all, i meet a segment fault when using libxo compiled with gcc 10 or gcc
trunk.

I found we can skip this problem when add attribute((noinline)) on the wrong
function  "xo_xml_leader_len".

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)

Program received signal SIGSEGV, Segmentation fault.
0x0000fffff7f9d4b8 in xo_xml_leader_len (nlen=0, name=0x0, xop=0xfffff7ddbe00)
at ../../libxo/libxo.c:567
567         if (name == NULL || isalpha(name[0]) || name[0] == '_')
(gdb) bt
#0  0x0000fffff7f9d4b8 in xo_xml_leader_len (nlen=0, name=0x0,
xop=0xfffff7ddbe00) at ../../libxo/libxo.c:567
#1  xo_format_value (xop=xop@entry=0xfffff7ddbe00, name=name@entry=0x0,
nlen=nlen@entry=0, value=value@entry=0x0, vlen=vlen@entry=0, fmt=0x4006e4
"%-*.*s}{etk:name}{eq:flags/0x%x}", flen=6, encoding=0x0, elen=0,
    flags=flags@entry=64) at ../../libxo/libxo.c:4362
#2  0x0000fffff7f9f434 in xo_do_emit_fields (xop=xop@entry=0xfffff7ddbe00,
fields=fields@entry=0xffffffffe940, max_fields=max_fields@entry=9, fmt=0x4006e0
"{d:/%-*.*s}{etk:name}{eq:flags/0x%x}")
    at ../../libxo/libxo.c:6372
#3  0x0000fffff7f9fa60 in xo_do_emit (xop=xop@entry=0xfffff7ddbe00,
flags=<optimized out>, flags@entry=0, fmt=fmt@entry=0x4006e0
"{d:/%-*.*s}{etk:name}{eq:flags/0x%x}") at ../../libxo/libxo.c:6551
#4  0x0000fffff7f9fd04 in xo_emit (fmt=0x4006e0
"{d:/%-*.*s}{etk:name}{eq:flags/0x%x}") at ../../libxo/libxo.c:6622
#5  0x00000000004006b4 in main (argc=1, argv=0xffffffffef98) at test.c:5
```

[Bug ipa/112783] core dump on libxo when function is inlined

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://github.com/Juniper/
                   |                            |libxo/issues/90
                 CC|                            |sjames at gcc dot gnu.org

--- Comment #1 from Sam James <sjames at gcc dot gnu.org> ---
Please see the instructions at https://gcc.gnu.org/bugs/#report, in particular
with regard to checking code with certain options, and also wrt test cases.

[Bug ipa/112783] core dump on libxo when function is inlined

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
   0x000000000040d178 <+152>:   call   0x401280 <__ctype_b_loc@plt>
=> 0x000000000040d17d <+157>:   movsbq (%r15),%rcx

r15            0x0                 0


Seeing if I can reduce it ...

[Bug ipa/112783] core dump on libxo when function is inlined

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The problem is not in GCC but rather a bad assumption on the code part.

Basically we have:

memcpy(nbuf, name, nlen);
...


if (!name)
...


But the check after a memcpy can be removed as passing a null pointer to memcpy
is undefined even if nlen is 0 here.


This patch to the sources 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);

```

[Bug ipa/112783] core dump on libxo when function is inlined

[yancheng.li at foxmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783

yancheng.li at foxmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

--- Comment #4 from yancheng.li at foxmail dot com ---
Thanks for your reply andrew. It really solved my problem.

[Bug ipa/112783] core dump on libxo when function is inlined

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |INVALID

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

[Bug ipa/112783] core dump on libxo when function is inlined

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |MOVED

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

[Bug ipa/112783] core dump on libxo when function is inlined

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jerry DeLisle <jvdelisle@gcc.gnu.org>:

https://gcc.gnu.org/g:a1f0d227481fe143f8c15b3f268e2d5964a3c90a

commit r14-6606-ga1f0d227481fe143f8c15b3f268e2d5964a3c90a
Author: Jerry DeLisle <jvdelisle@gcc.gnu.org>
Date:   Fri Dec 15 13:05:18 2023 -0800

    fortran: Update degree trigs documentation.

    This is only some cleanup.

    gcc/fortran/ChangeLog:

            PR fortran/112783

            * intrinsic.texi: Fix where no COMPLEX allowed.
            * invoke.texi: Clarify -fdev-math.

[Bug ipa/112783] core dump on libxo when function is inlined

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu.org

--- Comment #8 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to GCC Commits from comment #7)
> The master branch has been updated by Jerry DeLisle <jvdelisle@gcc.gnu.org>:
> 
> https://gcc.gnu.org/g:a1f0d227481fe143f8c15b3f268e2d5964a3c90a
> 
> commit r14-6606-ga1f0d227481fe143f8c15b3f268e2d5964a3c90a
> Author: Jerry DeLisle <jvdelisle@gcc.gnu.org>
> Date:   Fri Dec 15 13:05:18 2023 -0800
> 
>     fortran: Update degree trigs documentation.
>     
>     This is only some cleanup.
>     
>     gcc/fortran/ChangeLog:
>     
>             PR fortran/112783
>     
>             * intrinsic.texi: Fix where no COMPLEX allowed.
>             * invoke.texi: Clarify -fdev-math.

Typoe the PR number. Ignore should be 112873

[Bug ipa/112783] core dump on libxo when function is inlined

[jiangchuanganghw at outlook dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783

Jiang ChuanGang <jiangchuanganghw at outlook dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jiangchuanganghw at outlook dot co
                   |                            |m

--- Comment #9 from Jiang ChuanGang <jiangchuanganghw at outlook dot com> ---
(In reply to Andrew Pinski from comment #3)
> The problem is not in GCC but rather a bad assumption on the code part.
> 
> Basically we have:
> 
> memcpy(nbuf, name, nlen);
> ...
> 
> 
> if (!name)
> ...
> 
> 
> But the check after a memcpy can be removed as passing a null pointer to
> memcpy is undefined even if nlen is 0 here.
> 
> 
> This patch to the sources 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);
> 
> ```

I've encountered the same bug, and your solution does fix it.
But strangely enough, I can't reproduce it with code like the following.
The inevitable condition of this bug still puzzles me. Do you have any thoughts
on this.


#include <stdio.h>
#include <string.h>

static const char *xo_xml_leader_len(const char *name, int len)
{
    if (name == NULL || name[0] == '_')
            return "";
        return "_";
}

void test()
{
    char *name = NULL;
        int len = 0;
        char mbuf[len + 1];
        memcpy(mbuf, name, len);
        mbuf[len] = '\0';
        const char *leader = xo_xml_leader_len(name, len);
        printf("leader: %s", leader);
}

int main()
{
    test();
        return 0;
}

[Bug ipa/112783] core dump on libxo when function is inlined

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #10 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Jiang ChuanGang from comment #9)

> I've encountered the same bug, and your solution does fix it.
> But strangely enough, I can't reproduce it with code like the following.
> The inevitable condition of this bug still puzzles me. Do you have any
> thoughts on this.

If you invoke an undefined behavior then anything can happen.  And the
condition is not "inevitable", if you use a different compiler or use different
compile options it may change as well.

Do not try to predict the outcome of an undefined behavior.  If you really want
an explanation you can try to trace how the compiler optimizes the program (by
adding -fdump-tree-all -fdump-rtl-all and investigating all the dumped files). 
But such an explanation will only apply for the specific GCC version you are
using, with a different GCC release the optimization passes will just change. 
So I don't think such an explanation will be useful or worth to find out.

If you want to catch such bugs more easily try things like -fsanitize=undefined
or -fsanitize=address.