Segmentation fault: 11 #194

jwoertink · 2017-04-21T23:35:07Z

After building from source, I got this error:

[16:30PM] sandbox$ /Users/jeremywoertink/Development/lwan/build/lwan/lwan -r ./
Serving files from ./.
Using 8 threads, maximum 1280 sockets per thread.
Listening on http://0.0.0.0:8080.
Ready to serve.
Segmentation fault: 11

I'm running on macOS 10.12.3 built with cmake 3.7.0 and running the default LLVM 8.0.0.

The text was updated successfully, but these errors were encountered:

lpereira · 2017-04-22T04:36:31Z

Thanks for the bug report. My OS X machine is completely broken at the moment, so I cannot reproduce this. Could you please provide a backtrace using gdb? (If you don't know how, just ask.)

jwoertink · 2017-04-22T04:59:58Z

I'm not sure if this is correct or not:

[21:58PM] lwan (master)$ ./lwan gdb
6924118 lwan-job.c:79 lwan_job_thread_init() Initializing low priority job thread.
6924118 lwan-tables.c:40 lwan_tables_init() Uncompressing MIME type table.
6924118 lwan.c:60 lwan_module_init() Initializing module registry.
6924118 lwan.c:397 setup_from_config() Loading configuration file: lwan.conf.
6924118 lwan-config.c:664 config_open() Could not open configuration file: lwan.conf: No such file or directory (error number 2).
6924118 lwan.c:559 lwan_init_with_config() Could not read config file, using defaults.
6924118 lwan-response.c:77 lwan_response_init() Initializing default response.
6924118 lwan.c:568 lwan_init_with_config() Initializing lwan web server.
6924118 lwan.c:589 lwan_init_with_config() Using 8 threads, maximum 1280 sockets per thread.
6924118 lwan-thread.c:471 lwan_thread_init() Initializing threads.
6924120 lwan-thread.c:350 thread_io_loop() Starting IO loop on thread #1.
6924121 lwan-thread.c:350 thread_io_loop() Starting IO loop on thread #2.
6924122 lwan-thread.c:350 thread_io_loop() Starting IO loop on thread #3.
6924124 lwan-thread.c:350 thread_io_loop() Starting IO loop on thread #5.
6924125 lwan-thread.c:350 thread_io_loop() Starting IO loop on thread #6.
6924126 lwan-thread.c:350 thread_io_loop() Starting IO loop on thread #7.
6924123 lwan-thread.c:350 thread_io_loop() Starting IO loop on thread #4.
6924127 lwan-thread.c:350 thread_io_loop() Starting IO loop on thread #8.
6924118 lwan-thread.c:483 lwan_thread_init() IO threads created and ready to serve.
6924118 lwan-socket.c:240 lwan_socket_init() Initializing sockets.
6924118 lwan-socket.c:159 listen_addrinfo() Listening on http://127.0.0.1:8080.
6924118 lwan.c:667 lwan_main_loop() Ready to serve.
Segmentation fault: 11

The first one I compiled with -DCMAKE_BUILD_TYPE=Release, but this one I compiled with -DCMAKE_BUILD_TYPE=Debug

I tried from gdb to do this:

(gdb) file lwan
Reading symbols from lwan...done.
(gdb) run
Starting program: /Users/jeremywoertink/Development/lwan/build/lwan/lwan 
During startup program terminated with signal ?, Unknown signal.
(gdb) backtrace
No stack.

but didn't get anything back.

lpereira · 2017-04-22T14:40:17Z

You have to do the other way around: gdb lwan. (Otherwise, you're passing the "gdb" argument to Lwan, and it's ignoring that.)

Does Lwan crash right after starting up, or when a connection is made by a client?

jwoertink · 2017-04-22T18:30:56Z

lol, oh yeah. Well, that fails too. But when I boot lwan, it actually stays running until a client tries to connect. That's when it fails.

lpereira · 2017-04-23T18:19:41Z

Are you able to get a backtrace when running it that way?

jwoertink · 2017-04-23T23:41:07Z

I may not be doing this right still, but this is what I get:

[16:40PM] lwan (master)$ gdb lwan 
GNU gdb (GDB) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin16.1.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from lwan...done.
(gdb) run
Starting program: /Users/jeremywoertink/Development/lwan/build/lwan/lwan 
During startup program terminated with signal ?, Unknown signal.
(gdb) backtrace
No stack.
(gdb)

lampmanyao · 2017-04-27T15:50:34Z

@jwoertink You should try to run with lldb.
Here is my backtrace:
compiled with -DCMAKE_BUILD_TYPE=Debug

Process 15970 stopped

thread nginx vs lwan on gentoo #2, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x00007fffd361c6dc libsystem_c.dylibinet_ntop4 + 62 libsystem_c.dylibinet_ntop4:
-> 0x7fffd361c6dc <+62>: movaps %xmm0, -0x40(%rbp)
0x7fffd361c6e0 <+66>: movl $0x4, %r14d
0x7fffd361c6e6 <+72>: leaq 0x1dfcb(%rip), %r12 ; "%d"
0x7fffd361c6ed <+79>: xorl %r15d, %r15d

and complied with -DCMAKE_BUILD_TYPE=Release

Process 16356 stopped

thread nginx vs lwan on gentoo #2, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x00000001000167e4 lwanprocess_request_coro + 68 lwanprocess_request_coro:
-> 0x1000167e4 <+68>: movaps %xmm0, -0x40(%rbp)
0x1000167e8 <+72>: movaps %xmm0, -0x50(%rbp)
0x1000167ec <+76>: xorl %edi, %edi
0x1000167ee <+78>: movl $0x80, %esi

How to fix it on OS X:

Release mode: disable link time optimization
Debug mode: use -fsanitize=address instead of -fsanitize=undefined

jwoertink · 2017-04-27T16:03:31Z

@lampmanyao Are these fixes something I need to do when I compile, or are they fixes for the project?

jwoertink · 2017-04-28T16:26:52Z

Ok, I tried out lldb, and got some output here

(lldb) run
Process 43359 launched: '/Users/jeremywoertink/Development/lwan/build/lwan/lwan' (x86_64)
4935246 lwan-job.c:79 lwan_job_thread_init() Initializing low priority job thread.
4935246 lwan-tables.c:40 lwan_tables_init() Uncompressing MIME type table.
4935246 lwan.c:60 lwan_module_init() Initializing module registry.
4935246 lwan.c:397 setup_from_config() Loading configuration file: lwan.conf.
4935246 lwan-config.c:664 config_open() Could not open configuration file: lwan.conf: No such file or directory (error number 2).
4935246 lwan.c:559 lwan_init_with_config() Could not read config file, using defaults.
4935246 lwan-response.c:77 lwan_response_init() Initializing default response.
4935246 lwan.c:568 lwan_init_with_config() Initializing lwan web server.
4935246 lwan.c:589 lwan_init_with_config() Using 8 threads, maximum 1280 sockets per thread.
4935246 lwan-thread.c:471 lwan_thread_init() Initializing threads.
4935280 lwan-thread.c:350 thread_io_loop() Starting IO loop on thread #1.
4935281 lwan-thread.c:350 thread_io_loop() Starting IO loop on thread #2.
4935282 lwan-thread.c:350 thread_io_loop() Starting IO loop on thread #3.
4935283 lwan-thread.c:350 thread_io_loop() Starting IO loop on thread #4.
4935284 lwan-thread.c:350 thread_io_loop() Starting IO loop on thread #5.
4935285 lwan-thread.c:350 thread_io_loop() Starting IO loop on thread #6.
4935286 lwan-thread.c:350 thread_io_loop() Starting IO loop on thread #7.
4935287 lwan-thread.c:350 thread_io_loop() Starting IO loop on thread #8.
4935246 lwan-thread.c:483 lwan_thread_init() IO threads created and ready to serve.
4935246 lwan-socket.c:240 lwan_socket_init() Initializing sockets.
4935246 lwan-socket.c:159 listen_addrinfo() Listening on http://127.0.0.1:8080.
4935246 lwan.c:667 lwan_main_loop() Ready to serve.
Process 43359 stopped
* thread #2: tid = 0x4b4e76, 0x00007fff9f38f6dc libsystem_c.dylib`inet_ntop4 + 62, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x00007fff9f38f6dc libsystem_c.dylib`inet_ntop4 + 62
libsystem_c.dylib`inet_ntop4:
->  0x7fff9f38f6dc <+62>: movaps %xmm0, -0x40(%rbp)
    0x7fff9f38f6e0 <+66>: movl   $0x4, %r14d
    0x7fff9f38f6e6 <+72>: leaq   0x1dfcb(%rip), %r12       ; "%d"
    0x7fff9f38f6ed <+79>: xorl   %r15d, %r15d

(lldb) thread backtrace
* thread #2: tid = 0x4b4e76, 0x00007fff9f38f6dc libsystem_c.dylib`inet_ntop4 + 62, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x00007fff9f38f6dc libsystem_c.dylib`inet_ntop4 + 62
    frame #1: 0x000000010000d5fe lwan`lwan_request_get_remote_address(request=0x0000000101c629c8, buffer="\x88$?\x01") + 350 at lwan-request.c:1280
    frame #2: 0x0000000100011a33 lwan`log_request(request=0x0000000101c629c8, status=HTTP_NOT_FOUND) + 51 at lwan-response.c:123
    frame #3: 0x00000001000109da lwan`lwan_response(request=0x0000000101c629c8, status=HTTP_NOT_FOUND) + 314 at lwan-response.c:167
    frame #4: 0x0000000100011b91 lwan`lwan_default_response(request=0x0000000101c629c8, status=HTTP_NOT_FOUND) + 129 at lwan-response.c:217
    frame #5: 0x000000010000cb3b lwan`lwan_process_request(l=0x00007fff5fbff1e8, request=0x0000000101c629c8, buffer=0x0000000101c62ad8, next_request=0x0000000000000000) + 507 at lwan-request.c:1190
    frame #6: 0x000000010001c9df lwan`process_request_coro(coro=0x0000000101c59b00) + 463 at lwan-thread.c:183
    frame #7: 0x000000010000852a lwan`coro_entry_point(coro=0x0000000101c59b00, func=(lwan`process_request_coro at lwan-thread.c:141)) + 26 at lwan-coro.c:159

lpereira · 2017-04-28T17:20:11Z

Thanks, that looks promising. I need some additional information, though. Could you please post the output of the following commands inside lldb?

register read
frame info

jwoertink · 2017-04-28T17:23:29Z

Here you go.

Process 44849 stopped
* thread #2: tid = 0x4e5c70, 0x00007fff9f38f6dc libsystem_c.dylib`inet_ntop4 + 62, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x00007fff9f38f6dc libsystem_c.dylib`inet_ntop4 + 62
libsystem_c.dylib`inet_ntop4:
->  0x7fff9f38f6dc <+62>: movaps %xmm0, -0x40(%rbp)
    0x7fff9f38f6e0 <+66>: movl   $0x4, %r14d
    0x7fff9f38f6e6 <+72>: leaq   0x1dfcb(%rip), %r12       ; "%d"
    0x7fff9f38f6ed <+79>: xorl   %r15d, %r15d
(lldb) register read
General Purpose Registers:
       rax = 0x0000000101c62374
       rbx = 0x0000000101c622e8
       rcx = 0x000000000000002e
       rdx = 0x000000000000002e
       rdi = 0x0000000101c62374
       rsi = 0x0000000101c62468
       rbp = 0x0000000101c62328
       rsp = 0x0000000101c622d8
        r8 = 0x0000000101c62370
        r9 = 0xe1e9c0dd036200fc
       r10 = 0x0000000000000010
       r11 = 0x0000000000000246
       r12 = 0x0000000000000000
       r13 = 0x0000000101c62374
       r14 = 0x0000000000000000
       r15 = 0x0000000000000000
       rip = 0x00007fff9f38f6dc  libsystem_c.dylib`inet_ntop4 + 62
    rflags = 0x0000000000010202
        cs = 0x000000000000002b
        fs = 0x0000000000000000
        gs = 0x0000000000000000

(lldb) frame info
frame #0: 0x00007fff9f38f6dc libsystem_c.dylib`inet_ntop4 + 62

lampmanyao · 2017-04-30T10:01:59Z

If compiled with -fsanitize=undefined, it crashed.
But if compiled with -fsanitize=address, it won't.

The former's call stack just like @jwoertink posted:

 * frame #0: 0x00007fffd361c69e libsystem_c.dylib`inet_ntop4
    frame #1: 0x000000010003e11f lwan`lwan_request_get_remote_address(request=0x0000000101019658, buffer="") at lwan-request.c:1280
    frame #2: 0x0000000100051485 lwan`log_request(request=0x0000000101019658, status=HTTP_NOT_FOUND) at lwan-response.c:123
    frame #3: 0x000000010004d228 lwan`lwan_response(request=0x0000000101019658, status=HTTP_NOT_FOUND) at lwan-response.c:167
    frame #4: 0x0000000100051cb0 lwan`lwan_default_response(request=0x0000000101019658, status=HTTP_NOT_FOUND) at lwan-response.c:217
    frame #5: 0x000000010003a680 lwan`lwan_process_request(l=0x00007fff5fbff0a8, request=0x0000000101019658, buffer=0x0000000101019768, next_request=0x0000000000000000) at lwan-request.c:1190
    frame #6: 0x000000010008001a lwan`process_request_coro(coro=0x0000000101010800) at lwan-thread.c:183
    frame #7: 0x00000001000257ed lwan`coro_entry_point(coro=0x0000000101010800, func=(lwan`process_request_coro at lwan-thread.c:141)) at lwan-coro.c:163

and the later's call stack is a little bit different:

    frame #0: 0x00007fffd361c69e libsystem_c.dylib`inet_ntop4
  * frame #1: 0x000000010016e19a libclang_rt.asan_osx_dynamic.dylib`wrap_inet_ntop + 922
    frame #2: 0x0000000100024bdc lwan`lwan_request_get_remote_address(request=0x000062e00000a160, buffer="j\x01") at lwan-request.c:1280
    frame #3: 0x00000001000304aa lwan`log_request(request=0x000062e00000a160, status=HTTP_NOT_FOUND) at lwan-response.c:123
    frame #4: 0x000000010002de12 lwan`lwan_response(request=0x000062e00000a160, status=HTTP_NOT_FOUND) at lwan-response.c:167
    frame #5: 0x000000010003096e lwan`lwan_default_response(request=0x000062e00000a160, status=HTTP_NOT_FOUND) at lwan-response.c:217
    frame #6: 0x00000001000227ef lwan`lwan_process_request(l=0x00007fff5fbfede0, request=0x000062e00000a160, buffer=0x000062e00000a0e0, next_request=0x0000000000000000) at lwan-request.c:1190
    frame #7: 0x000000010004d9fc lwan`process_request_coro(coro=0x000062e000000400) at lwan-thread.c:183
    frame #8: 0x000000010001688a lwan`coro_entry_point(coro=0x000062e000000400, func=(lwan`process_request_coro at lwan-thread.c:141)) at lwan-coro.c:163

If we set a break point at inet_ntop4() and debug it step instruction by step instruction, we could see the assembly code is exactly the same:

->  0x7fffd361c69e <+0>:   pushq  %rbp
    0x7fffd361c69f <+1>:   movq   %rsp, %rbp
    0x7fffd361c6a2 <+4>:   pushq  %r15
    0x7fffd361c6a4 <+6>:   pushq  %r14
    0x7fffd361c6a6 <+8>:   pushq  %r13
    0x7fffd361c6a8 <+10>:  pushq  %r12
    0x7fffd361c6aa <+12>:  pushq  %rbx
    0x7fffd361c6ab <+13>:  subq   $0x28, %rsp
    0x7fffd361c6af <+17>:  movq   %rdi, %r13
    0x7fffd361c6b2 <+20>:  leaq   0x8eb09b7(%rip), %rbx     ; __stack_chk_guard
    0x7fffd361c6b9 <+27>:  movq   (%rbx), %rbx
    0x7fffd361c6bc <+30>:  movq   %rbx, -0x30(%rbp)
    0x7fffd361c6c0 <+34>:  testq  %r13, %r13
    0x7fffd361c6c3 <+37>:  je     0x7fffd361c751            ; <+179>
    0x7fffd361c6c9 <+43>:  testq  %rsi, %rsi
    0x7fffd361c6cc <+46>:  je     0x7fffd361c741            ; <+163>
    0x7fffd361c6ce <+48>:  movl   %edx, -0x44(%rbp)
    0x7fffd361c6d1 <+51>:  movq   %rsi, -0x50(%rbp)
    0x7fffd361c6d5 <+55>:  leaq   -0x40(%rbp), %rbx
    0x7fffd361c6d9 <+59>:  xorps  %xmm0, %xmm0
    0x7fffd361c6dc <+62>:  movaps %xmm0, -0x40(%rbp)
    0x7fffd361c6e0 <+66>:  movl   $0x4, %r14d
    0x7fffd361c6e6 <+72>:  leaq   0x1dfcb(%rip), %r12       ; "%d"

It seems not a stack overflow. I can't figure it out what's the difference between -fsanitize=undefined and -fsanitize=address. :(

jwoertink · 2017-05-03T17:06:32Z

@lampmanyao How are you compiling with -fsanitize=address? If I run cmake .. -DCMAKE_BUILD_TYPE=Debug -fsanitize=address then I get CMake Error: The source directory blah does not exist.

When you build with that flag, does it work for you?

lpereira · 2017-05-03T17:14:16Z

That is a flag for the compiler/linker. Use -DASAN=OFF and -DUBSAN=OFF when invoking Cmake. These are only necessary if debugging. You might want to try a release build as well

…

On Wed, May 3, 2017, 10:06 Jeremy Woertink ***@***.***> wrote: @lampmanyao <https://github.com/LampmanYao> How are you compiling with -fsanitize=address? If I run cmake .. -DCMAKE_BUILD_TYPE=Debug -fsanitize=address then I get CMake Error: The source directory blah does not exist. When you build with that flag, does it work for you? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#194 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAA6mdqJF2R-wOTTKZg17rN2vM-gsMeSks5r2LQYgaJpZM4NE5RY> .

jwoertink · 2017-05-03T17:44:33Z

Ah, ok. So the release build still throws the segfault, but I pulled down the latest version on master and built with cmake .. -DCMAKE_BUILD_TYPE=Debug -DASAN=OFF -DUBSAN=OFF. When running, it doesn't tank like before, but it never loads. It just hangs there spinning. Making progress? 😂

lpereira · 2017-05-03T18:06:31Z

I'll really need to get a Mac to debug this. Preferably a new one, as the one I have now is a G4 Powerbook that barely runs 10.5.

…

On Wed, May 3, 2017, 10:44 Jeremy Woertink ***@***.***> wrote: Ah, ok. So the release build still throws the segfault, but I pulled down the latest version on master and built with cmake .. -DCMAKE_BUILD_TYPE=Debug -DASAN=OFF -DUBSAN=OFF. When running, it doesn't tank like before, but it never loads. It just hangs there spinning. Making progress? 😂 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#194 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAA6mfzUMzLa6HFiLEAo9ZH2Ni7BJRcfks5r2L0BgaJpZM4NE5RY> .

lampmanyao · 2017-05-04T16:27:57Z

@jwoertink try this: cmake .. -DCMAKE_BUILD_TYPE=Debug -DASAN=ON -DUBSAN=OFF, it would be ok.

jwoertink · 2017-05-04T16:46:52Z

lol. nope. Tried that, and I got this

[09:44AM] lwan (master)$ ./build/lwan/lwan 
4529327 lwan-job.c:96 lwan_job_thread_init() Initializing low priority job thread.
ASAN:DEADLYSIGNAL
=================================================================
==38048==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000900 (pc 0x7fffd9f8d342 bp 0x7fff51ac5980 sp 0x7fff51ac5948 T0)
==38048==The signal is caused by a WRITE memory access.
==38048==Hint: address points to the zero page.
    #0 0x7fffd9f8d341 in os_unfair_lock_lock (libsystem_platform.dylib:x86_64+0x5341)
    #1 0x10e2099eb in je_arena_dalloc_small (libjemalloc.2.dylib:x86_64+0x109eb)
    #2 0x10e1ff177 in free (libjemalloc.2.dylib:x86_64+0x6177)
    #3 0x10e171ed9 in status_out lwan-status.c:179
    #4 0x10e171c52 in lwan_status_debug_debug lwan-status.c:212
    #5 0x10e153939 in lwan_job_thread_init lwan-job.c:96
    #6 0x10e142bba in lwan_init_with_config lwan.c:551
    #7 0x10e142b4b in lwan_init lwan.c:528
    #8 0x10e13bdac in main main.c:131
    #9 0x7fffd9d7b234 in start (libdyld.dylib:x86_64+0x5234)

==38048==Register values:
rax = 0x0000000000000000  rbx = 0x0000000000000900  rcx = 0x000060c000001010  rdx = 0x000060c000001430  
rdi = 0x0000000000000900  rsi = 0x0000000000000307  rbp = 0x00007fff51ac5980  rsp = 0x00007fff51ac5948  
 r8 = 0x000000000000000b   r9 = 0x7ffffffffffff000  r10 = 0xffffffffffffffff  r11 = 0x0000000000012068  
r12 = 0x0000000111c0d008  r13 = 0x000060c000000000  r14 = 0x000060c00000b8c0  r15 = 0x0000000000000000  
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (libsystem_platform.dylib:x86_64+0x5341) in os_unfair_lock_lock
==38048==ABORTING
Abort trap: 6

lpereira · 2017-07-13T05:58:21Z

It seems that this issue has been fixed today. It was a stack misalignment on x86_64 that caused the code to crash on an SSE instruction (that requires 16-byte alignment). Could you please recheck, @jwoertink?

jwoertink · 2017-07-13T15:33:13Z

Sweet! Yup. I got the "It works!" page 👍 I think we're ok to close this out. Thanks for the update.

lampmanyao · 2017-07-17T12:29:46Z

./lwan --help
[1] 15952 killed ./lwan --help

or

lldb ./lwan
(lldb) target create "./lwan"
Current executable set to './lwan' (x86_64).
(lldb) run
error: error: ::posix_spawnp ( pid => 16121, path = './lwan', file_actions = 0x7fff5fbde278, attr = 0x7fff5fbde288, argv = 0x7fc380c75660, envp = 0x7fc380c71ac0 ) err = Malformed Mach-o file (0x00000058)
(lldb) bt
error: invalid process

lpereira · 2017-07-17T15:26:54Z

That's weird. Is this on OS X 10.12?

…

On Mon, Jul 17, 2017, 05:29 lampman ***@***.***> wrote: ./lwan --help [1] 15952 killed ./lwan --help or lldb ./lwan (lldb) target create "./lwan" Current executable set to './lwan' (x86_64). (lldb) run error: error: ::posix_spawnp ( pid => 16121, path = './lwan', file_actions = 0x7fff5fbde278, attr = 0x7fff5fbde288, argv = 0x7fc380c75660, envp = 0x7fc380c71ac0 ) err = Malformed Mach-o file (0x00000058) (lldb) bt error: invalid process — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#194 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAA6mU4F3MGWAfX-73alzKwAWd0QlBFXks5sO1O6gaJpZM4NE5RY> .

jwoertink · 2017-07-17T15:37:27Z

Help command works fine for me, and I'm on 10.12.5. I built with the release flag.

lampmanyao · 2017-07-17T16:38:48Z

Yes. I am on 10.12.5 too. Whatever Release flag or Debug flag, it was killed. @lpereira @jwoertink

lpereira · 2017-07-17T17:58:25Z

Only when using --help? Anything else works? If you break on main, can you step through it to see where it crashes?

lampmanyao · 2017-07-18T01:44:26Z

No. Everything got killed. And i tried to set a breakpoint on main:

lldb ./lwan
(lldb) target create "./lwan"
Current executable set to './lwan' (x86_64).
(lldb) b main
Breakpoint 1: where = lwan`main + 62 at main.c:108, address = 0x0000000000001fee
(lldb) run
error: error: ::posix_spawnp ( pid => 16701, path = './lwan', file_actions = 0x7fff5814c278, attr = 0x7fff5814c288, argv = 0x7fcd7dcbba80, envp = 0x7fcd7dcbc070 ) err = Malformed Mach-o file (0x00000058)

lpereira · 2017-07-18T04:37:10Z

The error says "Malformed Mach-o file". Did you try removing the binary and creating it again? Maybe "make clean all"?

lampmanyao · 2017-07-19T12:07:39Z

I tried. But it still crashes.

gleicon · 2018-07-27T00:42:06Z

I'm getting that with MacOS High Sierra, cmake 3.12.0 and llvm;xcode sdk:

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-902.0.39.2)
Target: x86_64-apple-darwin17.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Looks like a cmake mistake as other projects report link wreckage with it.

$ otool -v -h ./src/bin/lwan/lwan
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL LIB64 EXECUTE 17 2056 NOUNDEFS DYLDLINK TWOLEVEL PIE

jwoertink closed this as completed Jul 13, 2017

lpereira mentioned this issue Jul 15, 2017

MacOS - Killed 9 Problem... #170

Closed

gleicon mentioned this issue Jul 27, 2018

Macos compile #237

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Segmentation fault: 11 #194

Segmentation fault: 11 #194

jwoertink commented Apr 21, 2017

lpereira commented Apr 22, 2017

jwoertink commented Apr 22, 2017 •

edited

Loading

lpereira commented Apr 22, 2017

jwoertink commented Apr 22, 2017

lpereira commented Apr 23, 2017

jwoertink commented Apr 23, 2017

lampmanyao commented Apr 27, 2017

jwoertink commented Apr 27, 2017

jwoertink commented Apr 28, 2017

lpereira commented Apr 28, 2017

jwoertink commented Apr 28, 2017

lampmanyao commented Apr 30, 2017 •

edited

Loading

jwoertink commented May 3, 2017

lpereira commented May 3, 2017 via email

jwoertink commented May 3, 2017

lpereira commented May 3, 2017 via email

lampmanyao commented May 4, 2017

jwoertink commented May 4, 2017

lpereira commented Jul 13, 2017

jwoertink commented Jul 13, 2017

lampmanyao commented Jul 17, 2017

lpereira commented Jul 17, 2017 via email

jwoertink commented Jul 17, 2017

lampmanyao commented Jul 17, 2017

lpereira commented Jul 17, 2017

lampmanyao commented Jul 18, 2017

lpereira commented Jul 18, 2017

lampmanyao commented Jul 19, 2017

gleicon commented Jul 27, 2018

Segmentation fault: 11 #194

Segmentation fault: 11 #194

Comments

jwoertink commented Apr 21, 2017

lpereira commented Apr 22, 2017

jwoertink commented Apr 22, 2017 • edited Loading

lpereira commented Apr 22, 2017

jwoertink commented Apr 22, 2017

lpereira commented Apr 23, 2017

jwoertink commented Apr 23, 2017

lampmanyao commented Apr 27, 2017

jwoertink commented Apr 27, 2017

jwoertink commented Apr 28, 2017

lpereira commented Apr 28, 2017

jwoertink commented Apr 28, 2017

lampmanyao commented Apr 30, 2017 • edited Loading

jwoertink commented May 3, 2017

lpereira commented May 3, 2017 via email

jwoertink commented May 3, 2017

lpereira commented May 3, 2017 via email

lampmanyao commented May 4, 2017

jwoertink commented May 4, 2017

lpereira commented Jul 13, 2017

jwoertink commented Jul 13, 2017

lampmanyao commented Jul 17, 2017

lpereira commented Jul 17, 2017 via email

jwoertink commented Jul 17, 2017

lampmanyao commented Jul 17, 2017

lpereira commented Jul 17, 2017

lampmanyao commented Jul 18, 2017

lpereira commented Jul 18, 2017

lampmanyao commented Jul 19, 2017

gleicon commented Jul 27, 2018

jwoertink commented Apr 22, 2017 •

edited

Loading

lampmanyao commented Apr 30, 2017 •

edited

Loading