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

clang segmentation fault on i386 architecture in -O2 #18545

Closed
llvmbot opened this issue Dec 7, 2013 · 4 comments
Closed

clang segmentation fault on i386 architecture in -O2 #18545

llvmbot opened this issue Dec 7, 2013 · 4 comments
Labels
bugzilla Issues migrated from bugzilla clang Clang issues not falling into any other category

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Dec 7, 2013

Bugzilla Link 18171
Resolution FIXED
Resolved on Mar 17, 2014 16:28
Version 3.3
OS FreeBSD
Attachments preprocessed editfns.c
Reporter LLVM Bugzilla Contributor
CC @d0k,@DimitryAndric

Extended Description

Emacs 24.3 when compiling on FreeBSD ends up with following segmentation fault:

% gdb temacs
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Environment variable "DISPLAY" not defined.
TERM = screen-bce
Breakpoint 1 at 0x80cd031: file emacs.c, line 350.
Breakpoint 2 at 0x80e6d08: file sysdep.c, line 850.
(gdb) core-file temacs.core
Core was generated by `temacs'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/librt.so.1...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /usr/lib/libexecinfo.so.1...done.
Loaded symbols for /usr/lib/libexecinfo.so.1
Reading symbols from /lib/libutil.so.9...done.
Loaded symbols for /lib/libutil.so.9
Reading symbols from /lib/libncurses.so.8...done.
Loaded symbols for /lib/libncurses.so.8
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libz.so.6...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/lib/libelf.so.1...done.
Loaded symbols for /usr/lib/libelf.so.1
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#​0 format_time_string (format=0x0, formatlen=1, t={tv_sec = 0, tv_nsec = 0}) at editfns.c:1787
1787 buf[0] = '\1';
[New Thread 83ab000 (LWP 100088/temacs)]
Current language: auto; currently minimal
(gdb) bt
#​0 format_time_string (format=0x0, formatlen=1, t={tv_sec = 0, tv_nsec = 0}) at editfns.c:1787
#​1 0x08133df8 in Fformat_time_string (format_string=, timeval=-1619017216) at editfns.c:1756
#​2 0x0813cfe6 in eval_sub (form=) at eval.c:2181
#​3 0x0813ce05 in eval_sub (form=) at eval.c:2139
#​4 0x0813ded1 in Flet (args=) at eval.c:936
#​5 0x0813cd77 in eval_sub (form=) at eval.c:2123
#​6 0x08140aeb in funcall_lambda (fun=, nargs=) at eval.c:458
#​7 0x0813f985 in apply_lambda (fun=138488846, args=) at eval.c:2914
#​8 0x0813cc54 in eval_sub (form=) at eval.c:2220
#​9 0x0813f94e in apply_lambda (fun=138781494, args=) at eval.c:2905
#​10 0x0813cc54 in eval_sub (form=) at eval.c:2220
#​11 0x0813ce05 in eval_sub (form=) at eval.c:2139
#​12 0x0813cea5 in eval_sub (form=) at eval.c:2160
#​13 0x0815b708 in readevalloop (readcharfun=138171994, stream=0x283eb34c, sourcename=, readfun=138064922, start=, end=) at lread.c:1887
#​14 0x0815a77d in Fload (file=, noerror=, nosuffix=, must_suffix=) at lread.c:1358
#​15 0x0813d045 in eval_sub (form=) at eval.c:2189
#​16 0x0815b708 in readevalloop (readcharfun=138171994, stream=0x283eb264, sourcename=, readfun=138064922, start=, end=) at lread.c:1887
#​17 0x0815a77d in Fload (file=, noerror=, nosuffix=, must_suffix=) at lread.c:1358
#​18 0x0813d045 in eval_sub (form=) at eval.c:2189
#​19 0x0813f716 in Feval (form=138093014, lexical=) at eval.c:1993
#​20 0x080df10a in top_level_2 () at keyboard.c:1179
#​21 0x0813eb40 in internal_condition_case (bfun=, handlers=, hfun=) at eval.c:1344

Following is the disassembly of the surrounding area:

0x08133ebe <format_time_string+158>: je 0x8133ed0 <format_time_string+176>
0x08133ec0 <format_time_string+160>: sub $0x4,%esp
0x08133ec3 <format_time_string+163>: lea 0x20(%esi),%eax
0x08133ec6 <format_time_string+166>: mov %eax,(%esp)
0x08133ec9 <format_time_string+169>: call 0x804bdcc gmtime@plt
0x08133ece <format_time_string+174>: jmp 0x8133ede <format_time_string+190>
0x08133ed0 <format_time_string+176>: sub $0x4,%esp
0x08133ed3 <format_time_string+179>: lea 0x20(%esi),%eax
0x08133ed6 <format_time_string+182>: mov %eax,(%esp)
0x08133ed9 <format_time_string+185>: call 0x804b0dc localtime@plt
0x08133ede <format_time_string+190>: add $0x4,%esp
0x08133ee1 <format_time_string+193>: mov %eax,%edx
0x08133ee3 <format_time_string+195>: test %edx,%edx
0x08133ee5 <format_time_string+197>: je 0x8134010 <format_time_string+496>
0x08133eeb <format_time_string+203>: mov $0xb,%ecx
0x08133ef0 <format_time_string+208>: mov 0x14(%ebp),%edi
0x08133ef3 <format_time_string+211>: mov %edx,%esi
0x08133ef5 <format_time_string+213>: rep movsl %ds:(%esi),%es:(%edi)
0x08133ef7 <format_time_string+215>: mov 0x1c(%esi),%ecx
0x08133efa <format_time_string+218>: movb $0x1,(%ecx)
0x08133efd <format_time_string+221>: sub $0x14,%esp
0x08133f00 <format_time_string+224>: mov 0xc(%ebp),%eax

Following is the unoptimized code for the block in question:

.LBB64_6: # in Loop: Header=BB64_1 Depth=1
movl $44, %eax
.loc 1 1785 0 # editfns.c:1785:0
movl 4104(%esi), %ecx
movl 80(%esi), %edx
subl $12, %esp
movl %ecx, (%esp)
movl %edx, 4(%esp)
movl $44, 8(%esp)
movl %eax, 48(%esi) # 4-byte Spill
calll memcpy
addl $12, %esp
.loc 1 1787 0 # editfns.c:1787:0
movl 100(%esi), %eax
movb $1, (%eax)

Following is the -O2 code for the block in question:

    .loc    1 1785 0                # editfns.c:1785:0
    movl    %edx, %esi              ########### %esi gets clobbered here, and never restored after 'rep movsl'
    rep;movsl
    movl    28(%esi), %ecx          # 4-byte Reload
    .loc    1 1787 0                # editfns.c:1787:0
    movb    $1, (%ecx)              ########### Segmentation Fault happens here

Following is the version of "clang":

FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 2013061
Target: i386-unknown-freebsd10.0
Thread model: posix

Let me know if you need more information to debug this.

Thanks

@d0k
Copy link
Member

d0k commented Dec 7, 2013

This is the unholy conjunction of dynamic alloca and stack realignment again.

  • When we reach the memcpy in @​format_time_string the check if %esi is used as a base pointer returns false. We emit a rep;movsl
  • Then we hit the dynamic alloca in a later BB in the function. We properly set all the flags needed to prevent further allocation of %esi, but it's already too late for the emitted rep;movsl.

@DimitryAndric
Copy link
Collaborator

*** Bug llvm/llvm-bugzilla-archive#18537 has been marked as a duplicate of this bug. ***

@DimitryAndric
Copy link
Collaborator

I can confirm this is now fixed by r202930 (see bug 19012). I will commit the (slightly modified) revision to FreeBSD 11.0-CURRENT soon.

@DimitryAndric
Copy link
Collaborator

mentioned in issue llvm/llvm-bugzilla-archive#18537

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 9, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla clang Clang issues not falling into any other category
Projects
None yet
Development

No branches or pull requests

3 participants