View Issue Details

IDProjectCategoryView StatusLast Update
0006090libmicrohttpdlibmicrohttpd APIpublic2020-02-19 19:03
ReporterrgaudinAssigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status newResolutionopen 
PlatformDarwinOSmacOSOS Version10.15.3
Product Version0.9.70 
Target VersionFixed in Version 
Summary0006090: MHD_start_daemon always fails on macOS
DescriptionAt least on versions 0.9.69 and 0.9.70, MHD_start_daemon() always fails on macOS catalina ; including on all of the doc/examples.

Compilation and linking raises no issue though.

Debug says "Failed to create socket for listening" with either "file not found" (0.9.69) or "undefined: 0" (0.9.70)

Known working version: 0.9.63.
Steps To ReproduceUsing 0.9.70 source code on macOS catalina:

./configure && make && ./doc/examples/hellobrowser && echo $?

hellobrowser returns immediately as daemon is NULL
TagsNo tags attached.

Activities

rgaudin

2020-02-12 09:14

reporter   ~0015349

Forgot to mention, I believe you're aware that version 0.9.64 to 0.9.68 (included) does not compile (for various reasons).

Christian Grothoff

2020-02-13 20:11

manager   ~0015353

Hmm. I don't have a MacOS here. Can you give us something like an strace of the syscalls on MacOS?

rgaudin

2020-02-14 10:05

reporter   ~0015354

Sure, here's the trace from dtrace using dtruss wrapper. Let me know if you need something more specific.

This is for 0.9.70 on hellobrowser example edited to add `MHD_USE_DEBUG`.
Program exits immediately (retcode 1) with output `Failed to create socket for listening: Undefined error: 0`.

hellobrowser_trace.log (104,912 bytes)

Christian Grothoff

2020-02-14 15:45

manager   ~0015355

Ok, looks to me like somehow disabling the SIGPIPE fails in mhd_sockets.c::MHD_socket_create_listen(). Some combintation of whatever #defines/constants are available must be the cause, resulting MHD in closing the already successfully opened (line 602) socket again in line 620.

I've removed some (as far as I can tell) redundant #ifdef checks in 902e3774..eda21a5c, but couldn't see what combination of these would be there on OS X that would cause this to fail. Anyway, someone on OS X who can find out which of these (SOCK_NOSIGPIPE, MSG_NOSIGNAL, etc.) is working/available should be able to fix this reasonably easily.

rgaudin

2020-02-14 17:36

reporter   ~0015356

Here's the trace using your last commit.

I could pin down the problem to the `#if defined(MHD_socket_nosignal_)` block in mhd_sockets.c ; after going through the `/* !SOCK_CLOEXEC */` else clause and properly creating the socket afterwards.

it seems to me that the problem lies with the if condition that follows as when commenting it all out, the daemon starts and everything seems to be running perfectly.

Here are the variable values:
nosigpipe_set 73896
MHD_socket_nosignal_ (fd) 1
MAYBE_MSG_NOSIGNAL 0

let me know what we could do to help. I can test stuff for you of course but if that helps, I'm sure we can arrange you a temporary SSH access to a macos machine.

hellobrowser_trace_eda21a5c2a9.log (161,302 bytes)

Christian Grothoff

2020-02-16 19:39

manager   ~0015366

Shell access would be the easiest way:

$ cat ~/.ssh/id_dsa.pub
ssh-dss AAAAB3NzaC1kc3MAAAIBAPmoUwxO5VkAR2j7AJh1/UfySsvtqPJWlzZ4i33LoNis6KpaHn7JO9dEL/psg10ZAqqqFahcTvqFDeXjS5DBzOHWA/u0TgXj58i1rOO2TgmxKF3UatYfD51omlPvw3IcnTPIX+Dsiq/cDkJAHxBdAYo9KjFGu9hM090UN7rY/ykBP/VwKbA/9fg0ASPgGrRF7JRylpMu424c8CbvM/iMZCew2BeE21g1u6WgewJjLgWcdGH2r4GO2FPvHSUlVJJ/wXdCDweboPsB+CuiEmBVruKcbG+DJddRWe4L7aUnIHTL6/i85bNwyjQ/toS2PFBx0jp04OcMyF7PxcIeEYI1+cimH//XIo3eOESGjRWpOKJR+yWlxcg2rKTFuHDO1tTTgqC+e2Kcvp7XrQPf4RuBWtD2YRGUMtEhQhvt2+Qd7KDQuuYR8TPXhHEh/sh7pQkCR/I9ijkxiPTCINjwkLD9X6tdYhT0XtG13dweog6EDrxXjtiIM1XY+jfTYvXVmDIn/lzvEfnhMkErTu/ZXt8bGVIRC5THDASFdQTnsCnVc1OU6AH3xVKa3F9CzOCwhrJ2EpQQMc8022ltmBYu9wFF0HPDoe56mqKdNnHDeaLp8CCuf9pLMeih9csYJlAQ3GsOzX9WR044+JqbS+b/++lOZjJdFlUlONZu0F+166rX4pipAAAAFQCA2XLNDkiQ93HpAFgZmBbavTVdxQAAAgA8cpggPUORDfTcgWgcdrJCQz4bIaGKdD/KhiLu15FqF02WkBYC8xsySK8DHkS41bHiqLB8vM5Yh2FiTjpwIzpQ9QH74JSdncUMxYncEcHrlHulASQZ7fuNMFK5vK7XVY2zAjrsjP+/H3vLrEOBoiI625gpGMTLB8QILBBbkGTpQ3Ks6LSJqEQfsCHmGYUhtkIQjgWIzDyzvvAOCjKMjNpkFyEKLkUYIWajt5y8AaFW5uNeXBqk5ejV4Y4pUg67zOJt92moqK5TQWIEjL0kKM7lFMXZDZow+DQQ47q9NYPLWVAwgWGbCdvvewWkJ5+xMTbxfTZgcUmvXz1zc/yGXoeSLoL+iJKyqQgEi6Jv8a+TnnTZivoxIgWYd/uByUvsxZrMXNlc1MUTKNI5CnEz3Dprb+qHw36SXKymnhSgC2948YRTWqU9emR8qNG8EKOoisHX9EPq+Ex5/IJQh2UlSScpnt2xANtoAZuEt/P5W6Djq6UtwMyI8E6yycEP+myKR/JKnydzjtxWEQV9ytfIQQkndPCr49N3RnrVA47aoBzhUQfiLyWbYFpc/oTZRhL5X86Sm9dXDhIyaPslSM8/C0DqzfhqOw53XxROj2IAAu3Aqsg4mkSEwuPzv2PTj0KjagGIuz3J/71CpUOz+6CUWh+tCzkYC3joLYXh0v/MUVZ5JgAAAgEA9IO/Nv4zdZtHSN2RN1lEyGGi+Oi5mFS5Wjo/tsw3VM53H7HiyxVCE8mcLWT/UOEcG4uitonxTUypZGhNra7sTkbje5tuLVKF99e3W4/wV6aWwLpryeZL5BOhlnmTJsZPgTuu3A7eNnh+C45L5SW7qmXLgS8jl3CKqGdzl3XO+eB5oN8EIjWGk+VbD0iPVYobDEUOo1TCj5ZGUENw4R6lRXKsPtHDqa+iMGSUa6hQXaM13oJTI+P4Dr9WcUjqbceHT3LPoYs8dCT9rrqHDX4HGIJr9A6aV/djPVoloPgONQVfqW+xci+yUVYLp8Xdj2zC8P0NCOWiFzke1v7fFvDzs2stotAfXtLvCHje2W4rbpz6InKfbysOEc/o2ybeb2Pu9F6oIamd9qiZhCGog422YyNh1+w1sAvUCBHuF38zPHxDB2YgF4tf2K4kU++PAuZOxnsYLErZly9Nxm2uGKvgKAEgaeMEYR1jK1llRmiGPIapJZIk3cav8tLEP6MNTrjDB52D56DeLdPrgL3cUfLtGcZOJhyBTcz5W07kyGQyT7VZiqlErsg6KQxRzEda6DWNYCAMc32yj8kgEY5hCt7ei1cfyL1Wox61rrdchjGgBDxikVeUL/Sw5H8Yuh8o7j6sT1RHfui5kW5M0ykCjKMniDiOE4sBtVSHFouERamDKA0= grothoff@gnunet.org

You can set the response with login details to 'private'.

Christian Grothoff

2020-02-18 23:10

manager   ~0015380

Sorry, but I cannot login. The server says:
debug1: Skipping ssh-dss key /home/grothoff/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes

Likely your configuration denies DSA for authentication. You can either enable DSA in the accepted key types, or I'm including my RSA key here as well:
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAgEArczTGb2rBEUa6mamO6jx5CILCMcF3ZWYlDOk7J0OavsqFV0bnpwKQVypW1TEXwFXgzXJvg6dKenpmWW3EPPN6S6mxxyA6O8dlBwRKLtaFQ5L1KBK1sGt9/1jN5UlyciYxoyKCpkb8RPqcb0u+uzO1o8LIiBbJc/52iiNv2FdgLIOFntWytoV63uXQ3gC1sMJWX/AgbifZpSAijYJEOOU3d1s2944EKT0ZmyC8mKm2lAq8/OoJGM0er3pD7jmd+5CLoiEQWUiOlNaJ14a1Pqv9DoqqsIsnJSrvigAX1JIdgD21BmD6nqwbzzE5SQUatC2yErRFHX0MZAJRpt+T1x56Gqt/+VUvVEB9dW0q5ZCBf18knlROjR8kXHyzbibiXk46W44oP3Uf21/MeoIEzhiXxODXMKuJnqDcxJHWN7/bHbEBDPdfucpLSChlx2F9tKRhfJhLJ/YItC9qUb800PXcAVW25un6KfRALlFSQuEhFoOCq8K5Eje5U/9RMvC0eFV/6V0bmlnDzicjC1XgBfjKL3oCvIxjZizKgrKgU+WT4Y1eT8oP2D8+HYAyYsEGhPYkMUY4Aqan+UcGJppeKA/3xFDEP/fa0Usvi1r9cMKgL3zt/23FTGCDz52cNq50sZgrkIQEUIfk4qGZi36L5GvZtGVU/oIGr7hwBmpAt/PefE= grothoff@gnunet.org

Christian Grothoff

2020-02-19 17:29

manager   ~0015387

Hmm. First of all, the system you gave me doesn't have gdb, so that makes debugging difficult. If you could install gdb, that would be great.

Second, most 'make check' tests pass, which is odd given that MHD_start_daemon() according to you always fails. So somehow the bug is not exactly reproduceable for me yet. Two tests failed (test_get_sendfile11 and test_get_chunked), which I will try to investigate (albeit without gdb, this may be tricky).

Christian Grothoff

2020-02-19 17:38

manager   ~0015388

Third, I just noticed I don't have dtrace/ttruss permissions either, so I can't debug the syscalls effectively. Sorry, that's not productive enough for me. Please give me _something_ other than fprintf-style debugging.
bash-3.2$ dtrace .libs/test_get_chunked
dtrace: failed to initialize dtrace: DTrace requires additional privileges
bash-3.2$ dtruss .libs/test_get_chunked
dtrace: failed to initialize dtrace: DTrace requires additional privileges

rgaudin

2020-02-19 18:34

reporter   ~0015389

Thank you Christian. I installed gdb (brew install gdb).
As for dtrace/dtruss, it won't be possible as we don't have root access to this machine…

I was suprised to see that indeed, it is working now so I tried to replicate and looking at what you did, I noticed the CFLAGS… I could get it running on my computer as well.
Trying different optimization levels, I realized that what make it work is no option in particular but just having CFLAGS defined.

With export CFLAGS="", the tests pass and hellobrowser works.
With unset CFLAGS, the tests fail and hellobrowser doesn't work.

Does that make any sense??

Christian Grothoff

2020-02-19 18:51

manager   ~0015390

Maybe not setting CFLAGS gives you O2 or so by default? That's the only thing that would make sense to me, even though then I'm confused as to where/why the compiler would generate different code that breaks stuff in MHD on this front. But, that's a good hint, I'll try with different CFLAGS once I'm done investigating the two failed tests.

Christian Grothoff

2020-02-19 18:53

manager   ~0015391

Anyway, gdb is still not working:

Reading symbols from .libs/test_get_chunked...
(gdb) break MHD_send_on_connection2_
Function "MHD_send_on_connection2_" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (MHD_send_on_connection2_) pending.
(gdb) break MHD_send_on_connection_
Function "MHD_send_on_connection_" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (MHD_send_on_connection_) pending.
(gdb) r
Starting program: /Users/user921770/libmicrohttpd/src/testcurl/.libs/test_get_chunked
Note: this version of macOS has System Integrity Protection.
Because `startup-with-shell' is enabled, gdb has worked around this by
caching a copy of your shell. The shell used by "run" is now:
    /Users/user921770/Library/Caches/gdb/bin/bash
Unable to find Mach task port for process-id 77754: (os/kern) failure (0x5).
 (please check gdb is codesigned - see taskgated(8))

rgaudin

2020-02-19 18:56

reporter   ~0015392

Just added echo "set startup-with-shell off" >> ~/.gdbinit
can you retry?

Christian Grothoff

2020-02-19 19:00

manager   ~0015394

That just gets rid of the warning. I still get:

$ gdb .libs/test_get_chunked
GNU gdb (GDB) 9.1
Copyright (C) 2020 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-darwin19.3.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 .libs/test_get_chunked...
(gdb) r
Starting program: /Users/user921770/libmicrohttpd/src/testcurl/.libs/test_get_chunked
Unable to find Mach task port for process-id 77807: (os/kern) failure (0x5).
 (please check gdb is codesigned - see taskgated(8))

rgaudin

2020-02-19 19:03

reporter   ~0015395

Ah right apparently we need to sign the binary as instructed in https://sourceware.org/gdb/wiki/PermissionsDarwin
It seems to requires a sudo call so I'll run those steps and open a ticket with the host to have it restart that service. will let you know pnce done.

Issue History

Date Modified Username Field Change
2020-02-11 17:24 rgaudin New Issue
2020-02-12 09:14 rgaudin Note Added: 0015349
2020-02-13 20:11 Christian Grothoff Note Added: 0015353
2020-02-13 20:11 Christian Grothoff Status new => feedback
2020-02-14 10:05 rgaudin File Added: hellobrowser_trace.log
2020-02-14 10:05 rgaudin Note Added: 0015354
2020-02-14 10:05 rgaudin Status feedback => new
2020-02-14 15:45 Christian Grothoff Note Added: 0015355
2020-02-14 17:36 rgaudin File Added: hellobrowser_trace_eda21a5c2a9.log
2020-02-14 17:36 rgaudin Note Added: 0015356
2020-02-16 19:39 Christian Grothoff Note Added: 0015366
2020-02-18 23:10 Christian Grothoff Note Added: 0015380
2020-02-19 17:29 Christian Grothoff Note Added: 0015387
2020-02-19 17:38 Christian Grothoff Note Added: 0015388
2020-02-19 18:34 rgaudin Note Added: 0015389
2020-02-19 18:51 Christian Grothoff Note Added: 0015390
2020-02-19 18:53 Christian Grothoff Note Added: 0015391
2020-02-19 18:56 rgaudin Note Added: 0015392
2020-02-19 19:00 Christian Grothoff Note Added: 0015394
2020-02-19 19:03 rgaudin Note Added: 0015395