[Bug ipa/112783] core dump on libxo when function is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #10 from Xi Ruoyao --- (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.
[Bug ipa/112783] core dump on libxo when function is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783
Jiang ChuanGang changed:
What|Removed |Added
CC||jiangchuanganghw at outlook
dot co
||m
--- Comment #9 from Jiang ChuanGang ---
(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
#include
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- (In reply to GCC Commits from comment #7) > The master branch has been updated by Jerry DeLisle : > > https://gcc.gnu.org/g:a1f0d227481fe143f8c15b3f268e2d5964a3c90a > > commit r14-6606-ga1f0d227481fe143f8c15b3f268e2d5964a3c90a > Author: Jerry DeLisle > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783 --- Comment #7 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:a1f0d227481fe143f8c15b3f268e2d5964a3c90a commit r14-6606-ga1f0d227481fe143f8c15b3f268e2d5964a3c90a Author: Jerry DeLisle 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |MOVED --- Comment #6 from Andrew Pinski --- .
[Bug ipa/112783] core dump on libxo when function is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #5 from Andrew Pinski --- .
[Bug ipa/112783] core dump on libxo when function is inlined
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Andrew Pinski ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783 --- Comment #2 from Andrew Pinski --- 0x0040d178 <+152>: call 0x401280 <__ctype_b_loc@plt> => 0x0040d17d <+157>: movsbq (%r15),%rcx r150x0 0 Seeing if I can reduce it ...
[Bug ipa/112783] core dump on libxo when function is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783 Sam James 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 --- 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.
