nvim failed t start with SIGABRT

[leira]

Trying to build top of master branch on change 1ce80d8, failed with Abort trap when generating tags.

/bin/sh: line 1: 35313 Abort trap: 6           /Users/leira/Source/github/neovim/build/bin/nvim -u NONE -i NONE -es --headless -c helptags\ ++t\ . -c quit
make[3]: *** [runtime/doc/tags] Error 134
make[2]: *** [runtime/CMakeFiles/runtime.dir/all] Error 2
make[1]: *** [all] Error 2
make: *** [nvim] Error 2

It was actually a nvim runtime error, I ran the newly built vim with lldb, and got this backtrace:

> lldb build/bin/nvim
(lldb) target create "build/bin/nvim"
Current executable set to 'build/bin/nvim' (x86_64).
(lldb) r
Process 35446 launched: '/Users/leira/Source/github/neovim/build/bin/nvim' (x86_64)
Process 35446 stopped
* thread #1: tid = 0x253079, 0x00007fff8764a0ae libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
frame #0: 0x00007fff8764a0ae libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff8764a0ae <+10>: jae    0x7fff8764a0b8            ; <+20>
0x7fff8764a0b0 <+12>: movq   %rax, %rdi
0x7fff8764a0b3 <+15>: jmp    0x7fff876453ef            ; cerror_nocancel
0x7fff8764a0b8 <+20>: retq
(lldb) bt
* thread #1: tid = 0x253079, 0x00007fff8764a0ae libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff8764a0ae libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00007fff907f0500 libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0x00007fff8843337b libsystem_c.dylib`abort + 129
frame #3: 0x00007fff884334f2 libsystem_c.dylib`abort_report_np + 181
frame #4: 0x00007fff884599cc libsystem_c.dylib`__chk_fail + 48
frame #5: 0x00007fff8845999c libsystem_c.dylib`__chk_fail_overflow + 16
frame #6: 0x00007fff88459be9 libsystem_c.dylib`__strcpy_chk + 83
frame #7: 0x000000010003fc6d nvim`eval_init + 189 at eval.c:511
frame #8: 0x0000000100103555 nvim`early_init + 37 at main.c:179
frame #9: 0x0000000100103730 nvim`main(argc=1, argv=0x00007fff5fbff718) + 128 at main.c:234
frame #10: 0x00007fff8b70e5ad libdyld.dylib`start + 1
frame #11: 0x00007fff8b70e5ad libdyld.dylib`start + 1
(lldb) f 7
frame #7: 0x000000010003fc6d nvim`eval_init + 189 at eval.c:511
   508
   509    for (i = 0; i < VV_LEN; ++i) {
   510      p = &vimvars[i];
-> 511      STRCPY(p->vv_di.di_key, p->vv_name);
   512      if (p->vv_flags & VV_RO)
   513        p->vv_di.di_flags = DI_FLAGS_RO | DI_FLAGS_FIX;
   514      else if (p->vv_flags & VV_RO_SBX)
(lldb) p p
(vimvar *) $0 = 0x00000001003153d0
(lldb) p *p
(vimvar) $1 = {
  vv_name = 0x00000001002e4a93 "count"
  vv_di = {
di_tv = {
  v_type = '\x01'
  v_lock = '\0'
  vval = {
    v_number = 0
    v_float = 0
    v_string = 0x0000000000000000 <no value available>
    v_list = 0x0000000000000000
    v_dict = 0x0000000000000000
  }
}
di_flags = '\0'
di_key = ([0] = 'c')
  }
  vv_filler = {
[0] = '\0'
[1] = '\0'
[2] = '\0'
[3] = '\0'
[4] = '\0'
[5] = '\0'
[6] = '\0'
[7] = '\0'
[8] = '\0'
[9] = '\0'
[10] = '\0'
[11] = '\0'
[12] = '\0'
[13] = '\0'
[14] = '\0'
[15] = '\0'
  }
  vv_flags = '\x03'
}
(lldb)

[leira]

Is there any work around I can try first?

[justinmk]

lldb build/bin/nvim

Hmm, it doesn't even require the helptags command, it happens just from startup? Does it happen with nvim -u NONE ?

[leira]

Same result.

> build/bin/nvim -u NONE
fish: 'build/bin/nvim -u NONE' terminated by signal SIGABRT (Abort)

[justinmk]

Oh, this is good ol' #223. Somewhere in your build system -D_FORTIFY_SOURCE=2 is getting past our painstaking attempts to prevent it. -D_FORTIFY_SOURCE=2 is not compatible with Vim nor Neovim because of a common C trick.

[fwalch]

Strange that this is still happening.. can you post the output of rm -rf build && make VERBOSE=1 as Gist?

[leira]

Build log uploaded to https://gist.github.com/leira/2c6cfe6b6f42dc2c3322. Actually, I didn't see -D_FORTIFY_SOURCE=2 in the command line. I was using clang-703.0.21, it's internal pre-release version, maybe it started using -D_FORTIFY_SOURCE=2 as default.

I changed the CMakeLists.txt file, removed "if(NOT HAS_ACCEPTABLE_FORTIFY)" check to force using "-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1", solved this issue.

[fwalch]

Strange.. even if it was using _FORTIFY_SOURCE=2 as (internal) default, it should trigger the HAS_ACCEPTABLE_FORTIFY check. Does the following compile with the pre-release clang?

#if defined(_FORTIFY_SOURCE) && _FORTIFY_SOURCE > 1
#error "_FORTIFY_SOURCE > 1"
#endif
int
main(void)
{
  return 0;
}

[leira]

Yes, this snippet does compile.

By "maybe it started using -D_FORTIFY_SOURCE=2 as default", I didn't mean it necessarily has a predefined _FORTIFY_SOURCE=2 macro, I meant maybe clang-703.0.21 take the default behavior just like _FORTIFY_SOURCE=2 is defined, that it will replace STRCPY with a safer version doing boundary check.

My question is, if "-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1" is required for certain source files to work properly, why not setting these extra flags for these source files in make files unconditionally, until they can be safely removed someday?

[fwalch]

My question is, if "-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1" is required for certain source files to work properly, why not setting these extra flags for these source files in make files unconditionally, until they can be safely removed someday?

I thought about that, too.. however, -D_FORTIFY_SOURCE=1 is not required, it's just that something doesn't work with -D_FORTIFY_SOURCE=2. We only replace it with -D_FORTIFY_SOURCE=1 so that there's at least some fortify if it has been explicitly requested. I don't know if it would be a good idea to enable it unconditionally e.g. for debug builds..

Is "clang-703.0.21" the 3.9.0 branch, btw?

Edit: Hm, probably doesn't change anything, but what happens if you compile with just "-U_FORTIFY_SOURCE"? That we could add unconditionally (and then append a "-D_FORTIFY.." if needed).

[leira]

I think I figured it out.

The check in CMakeList.txt compiles, but it failed with #error "_FORTIFY_SOURCE > 1" if a I put a #include <string.h> before it:

#include <string.h>
#if defined(_FORTIFY_SOURCE) && _FORTIFY_SOURCE > 1
#error "_FORTIFY_SOURCE > 1"
#endif
int
main(void)
{
  return 0;
}

I digged into <string.h> in my tool chain, in <_types.h> included in <string.h>, it defined FORTIFY_SOURCE=2:

#ifndef _FORTIFY_SOURCE
#  if defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) && ((__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__-0) < 1050)
#    define _FORTIFY_SOURCE 0
#  else
#    define _FORTIFY_SOURCE 2   /* on by default */
#  endif
#endif

So I suggest, can we add #include <string.h> in the HAS_ACCEPTABLE_FORTIFY check?

[leira]

"clang-703.0.21" is from the internal toolchain we used in our company, I'm not really sure which clang branch it is in.

[justinmk]

👍

[fwalch]

I digged into in my tool chain, in <_types.h> included in , it defined FORTIFY_SOURCE=2

Huh. I'd have never thought that behavior-changing constants would be set in a header file. Thanks for tracking this down!

@justinmk I'll send a PR, then.