View Issue Details

IDProjectCategoryView StatusLast Update
0006090libmicrohttpdlibmicrohttpd APIpublic2020-03-07 17:26
ReporterrgaudinAssigned ToChristian Grothoff 
Status resolvedResolutionfixed 
PlatformDarwinOSmacOSOS Version10.15.3
Product Version0.9.70 
Target Version0.9.71Fixed in Version0.9.71 
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.



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?


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.


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

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/
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=

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=

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


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:
Unable to find Mach task port for process-id 77754: (os/kern) failure (0x5).
 (please check gdb is codesigned - see taskgated(8))


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 <>
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:
Find the GDB manual and other documentation resources online at:

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))


2020-02-19 19:03

reporter   ~0015395

Ah right apparently we need to sign the binary as instructed in
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.

Christian Grothoff

2020-03-05 13:27

manager   ~0015417

Ok, the mystery deepens:

bash-3.2$ .libs/test_get_chunked
bash-3.2$ ./test_get_chunked
Failed to create socket for listening: Invalid argument
Failed to create socket for listening: Invalid argument
Failed to create socket for listening: Invalid argument
Failed to create socket for listening: Invalid argument
Error (code: 289)

Under dtruss, the .libs/test_get_chunked also passes just fine. Note that both of the above are the _same_ binary, just one is wrapped by the shell script. That would suggest that maybe without the wrapper I'm linking against a different version of, alias the tools I usually would use to find out are not available:

bash-3.2$ ldd .libs/test_get_chunked
bash: ldd: command not found
bash-3.2$ locate
(-> not working, no database).

Running a 'find' now to see if the theory of a second is plausible...

Christian Grothoff

2020-03-05 13:34

manager   ~0015418

dyldinfo would seem like the ldd replacement on OSX => also not installed :-(.


2020-03-05 13:35

reporter   ~0015419

Have you tried `otool -L` ?

Christian Grothoff

2020-03-05 13:36

manager   ~0015420


worked, forcing dyld to use the freshly installed, so now the error does also occur with:

$ .libs/test_get_chunked
Failed to create socket for listening: Invalid argument
Failed to create socket for listening: Invalid argument
Failed to create socket for listening: Invalid argument
Failed to create socket for listening: Invalid argument

(so my suspicion that there is a system-library with OTHER code installed was correct).


2020-03-05 13:37

reporter   ~0015421

otool -L .libs/test_get_chunked
    /usr/local/lib/libmicrohttpd.12.dylib (compatibility version 68.0.0, current version 68.0.0)
    /usr/local/opt/gnutls/lib/libgnutls.30.dylib (compatibility version 57.0.0, current version 57.2.0)
    /usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)

Let me get rid of that

Christian Grothoff

2020-03-05 13:38

manager   ~0015422

Interesting. Even though
$ .libs/test_get_chunked
now fails,
$ sudo dtruss -f .libs/test_get_chunked
still *succeeds*. So maybe it is not so much -O2 but some timing issue (with the optimization making the code more likely to hit the timing issue!?!?)


2020-03-05 13:38

reporter   ~0015423

I had installed it via brew during my tests I guess. It's gone now, can you retry?

Christian Grothoff

2020-03-05 13:41

manager   ~0015424

Tried gdb now, still seems not working:

bash-3.2$ 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 <>
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:
Find the GDB manual and other documentation resources online at:

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/christian/libmicrohttpd/src/testcurl/.libs/test_get_chunked
Unable to find Mach task port for process-id 22456: (os/kern) failure (0x5).
 (please check gdb is codesigned - see taskgated(8))

Christian Grothoff

2020-03-05 13:41

manager   ~0015425

Never mind, worked with sudo ;-)

Christian Grothoff

2020-03-05 13:43

manager   ~0015426

Ah, but now I get:

warning: unhandled dyld version (16)

from gdb. As a result, gdb refuses to enter into the library code, or to accept break points on library symbols (like MHD_start_daemon()).


Christian Grothoff

2020-03-05 13:46

manager   ~0015427

Just for fun, I tried 'hellobrowser' to see what was going on there, and with dtruss I now get:

22499/0x12b456: stat64("/etc/gnutls/config\0", 0x7FFEE3ECD380, 0x0) = -1 Err#2

which suggests that gnutls isn't properly installed. I'll next try without it...

Christian Grothoff

2020-03-05 13:51

manager   ~0015428

Ok, now without gnutls, the dtruss output is completely non-sensical:

$ sudo dtruss -af .libs/hellobrowser
30330/0x12eeae: 1665 104 47 open("/dev/dtracehelper\0", 0x2, 0xFFFFFFFFEB708F90) = 3 0
30330/0x12eeae: 2311 1216 636 ioctl(0x3, 0x80086804, 0x7FFEEB708EA0) = 0 0
30330/0x12eeae: 2322 10 7 close(0x3) = 0 0
30330/0x12eeae: 2491 10 5 mprotect(0x104515000, 0x1000, 0x1) = 0 0
30330/0x12eeae: 2497 6 3 mprotect(0x1044F7000, 0x1000, 0x1) = 0 0
30330/0x12eeae: 2660 14 10 access("/AppleInternal/XBS/.isChrooted\0", 0x0, 0x0) = -1 Err#2
30330/0x12eeae: 2743 16 11 bsdthread_register(0x7FFF6FE9F82C, 0x7FFF6FE9F818, 0x2000) = 1073742047 0
30330/0x12eeae: 2919 16 9 sysctlbyname(kern.bootargs, 0xD, 0x7FFEEB707FF0, 0x7FFEEB707FE0, 0x0) = 0 0
30330/0x12eeae: 3040 4 0 issetugid(0x0, 0x0, 0x0) = 0 0
30330/0x12eeae: 3190 15 2 ioctl(0x2, 0x4004667A, 0x7FFEEB708334) = 0 0
30330/0x12eeae: 3215 11 7 mprotect(0x104525000, 0x1000, 0x0) = 0 0
30330/0x12eeae: 3224 7 4 mprotect(0x10452A000, 0x1000, 0x0) = 0 0
30330/0x12eeae: 3245 4 1 mprotect(0x10452B000, 0x1000, 0x0) = 0 0
30330/0x12eeae: 3249 4 1 mprotect(0x104530000, 0x1000, 0x0) = 0 0
30330/0x12eeae: 3268 6 3 mprotect(0x104523000, 0x90, 0x1) = 0 0
30330/0x12eeae: 3280 5 2 mprotect(0x1044FC000, 0x1000, 0x1) = 0 0
30330/0x12eeae: 3287 7 4 mprotect(0x104523000, 0x90, 0x3) = 0 0
30330/0x12eeae: 3334 59 3 mprotect(0x104523000, 0x90, 0x1) = 0 0
30330/0x12eeae: 3587 8 4 getentropy(0x7FFEEB707840, 0x20, 0x0) = 0 0
30330/0x12eeae: 3588 2 0 getentropy(0x7FFEEB707890, 0x40, 0x0) = 0 0
30330/0x12eeae: 3769 5 1 getpid(0x0, 0x0, 0x0) = 30330 0
30330/0x12eeae: 3790 12 8 stat64("/AppleInternal\0", 0x7FFEEB708460, 0x0) = -1 Err#2
30330/0x12eeae: 3857 11 5 csops_audittoken(0x767A, 0x7, 0x7FFEEB707FB0) = -1 Err#22
30330/0x12eeae: 3878 14 10 proc_info(0x2, 0x767A, 0xD) = 64 0
30330/0x12eeae: 3922 7 3 csops_audittoken(0x767A, 0x7, 0x7FFEEB707830) = -1 Err#22
30330/0x12eeae: 4182 9 6 pipe(0x0, 0x0, 0x0) = 3 0
30330/0x12eeae: 4195 3 0 fcntl(0x3, 0x3, 0x4) = 0 0
30330/0x12eeae: 4196 2 1 fcntl(0x3, 0x4, 0x4) = 0 0
30330/0x12eeae: 4197 1 0 fcntl(0x4, 0x3, 0x0) = 1 0
30330/0x12eeae: 4198 1 0 fcntl(0x4, 0x4, 0x5) = 0 0
30330/0x12eeae: 4266 46 44 socket(0x2, 0x1, 0x0) = 5 0
30330/0x12eeae: 4296 14 11 close(0x5) = 0 0
30330/0x12eeae: 4317 3 1 close(0x3) = 0 0
30330/0x12eeae: 4319 2 1 close(0x4) = 0 0

Basically, all we can see is we open the socket and then close it (assuming that's OUR code). No failing syscalls. Very strange.

Christian Grothoff

2020-03-05 14:04

manager   ~0015429

Tried dtrace, again failed to get a sane syscall trace. Giving up for now: no working gdb, and the syscall tracers seem to not follow into newly created pthreads or are otherwise broken.


2020-03-05 14:05

reporter   ~0015430

OK will try to get gdb to run and come back to you.


2020-03-05 14:50

reporter   ~0015431

I don't think we'll get it running soon. the dyld version is the version of the linking format and current version of gdb doesn't support it:;a=blob;f=gdb/solib-darwin.c#l106

Would you be able to try lldb which was bundled and seems to work?

sudo lldb .libs/hellobrowser
(lldb) target create ".libs/hellobrowser"
Current executable set to '.libs/hellobrowser' (x86_64).
(lldb) breakpoint set -f hellobrowser.c -l 51
Breakpoint 1: where = hellobrowser`main + 55 at hellobrowser.c:51:12, address = 0x0000000100000ea7
(lldb) r
Process 2774 launched: '/Users/christian/libmicrohttpd/doc/examples/.libs/hellobrowser' (x86_64)
hellobrowser was compiled with optimization - stepping may behave oddly; variables may not be available.
Process 2774 stopped
* thread #1, queue = '', stop reason = breakpoint 1.1
    frame #0: 0x0000000100000ea7 hellobrowser`main at hellobrowser.c:51:12 [opt]
   50 &answer_to_connection, NULL, MHD_OPTION_END);
-> 51 if (NULL == daemon)
   52 return 1;
   54 (void) getchar ();
Target 0: (hellobrowser) stopped.
(lldb) frame var daemon
(MHD_Daemon *) daemon = <variable not available>


Christian Grothoff

2020-03-05 17:24

manager   ~0015432

Ok, so I've fixed two issues now. However, now the two "perf" tests segfault -- but only when run as part of 'make check'. If I run them under the debugger (lldb), they PASS. Very strange. I'd like to look at the core files, but they are not generated because I have no write access to /cores/. Could you fix that, or give me some other way to get to at least see how they died? Thanks!


2020-03-05 17:28

reporter   ~0015433

Does the files in ~/Library/Logs/DiagnosticReports/ help?

Christian Grothoff

2020-03-07 17:26

manager   ~0015436

Yes, thanks, that helped. All issues the test suite discovers are fixed in Git master now. You can now remove my account/access.

Christian Grothoff

2020-03-07 17:26

manager   ~0015437

Oh, and thanks for reporting & providing access.

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
2020-03-05 13:27 Christian Grothoff Note Added: 0015417
2020-03-05 13:34 Christian Grothoff Note Added: 0015418
2020-03-05 13:35 rgaudin Note Added: 0015419
2020-03-05 13:36 Christian Grothoff Note Added: 0015420
2020-03-05 13:37 rgaudin Note Added: 0015421
2020-03-05 13:38 Christian Grothoff Note Added: 0015422
2020-03-05 13:38 rgaudin Note Added: 0015423
2020-03-05 13:41 Christian Grothoff Note Added: 0015424
2020-03-05 13:41 Christian Grothoff Note Added: 0015425
2020-03-05 13:43 Christian Grothoff Note Added: 0015426
2020-03-05 13:46 Christian Grothoff Note Added: 0015427
2020-03-05 13:51 Christian Grothoff Note Added: 0015428
2020-03-05 14:04 Christian Grothoff Note Added: 0015429
2020-03-05 14:05 rgaudin Note Added: 0015430
2020-03-05 14:50 rgaudin Note Added: 0015431
2020-03-05 17:24 Christian Grothoff Note Added: 0015432
2020-03-05 17:28 rgaudin Note Added: 0015433
2020-03-07 17:26 Christian Grothoff Assigned To => Christian Grothoff
2020-03-07 17:26 Christian Grothoff Status new => resolved
2020-03-07 17:26 Christian Grothoff Resolution open => fixed
2020-03-07 17:26 Christian Grothoff Fixed in Version => 0.9.71
2020-03-07 17:26 Christian Grothoff Note Added: 0015436
2020-03-07 17:26 Christian Grothoff Target Version => 0.9.71
2020-03-07 17:26 Christian Grothoff Note Added: 0015437