It's possible that c-ares calls the callback function immediately in ares_gethostbyname, which may free the server
structure in that callback function.
* format with .uncrustify.cfg
format with .uncrustify.cfg
* format with .uncrustify.cfg
* format with .uncrustify.cfg exclude json.* base64.* uthash.h
* format with .uncrustify.cfg exclude json.* base64.* uthash.h
* Replace udns with c-ares
* Get IO loop work
* Clean up
* Avoid initializing nameservers each query
* Add ARES_OPT_SERVERS
* Refine resolv_cancel
* Fix a memory leak
* Replace udns.h with ares.h
* Fix all inet_* fucntions
* Clean up
* Enable servers_ports when VERSION_MINOR >= 11
* Avoid ares_inet_XtoX
* Handle multipe nameservers correctly
* Use ares_set_servers for IPv4 and IPv6 mixed list
* Refine c-ares for udprelay
* Refine ares_set_servers()
* Refine the timer based on ares_timeout
* Avoid resolv_cancel
* Fix an issue of null pointer
* Fix another null pointer issue
* Refine the order of resolv_shutdown
* Fix the corrupted ev io
In a few places `malloc` was being used without checking the return for
a `NULL` pointer. There's already a wrapper (`ss_malloc`) in
`util.c` that performs this check and exits if it fails so this commit
replaces the unsafe `malloc`s with `ss_malloc`s.
Sometimes we need processes to run in the foreground to be supervised
and at the same time use syslog facility instead of logging its stdout,
stderr output
When ss-server wrapped in a plugin server, every peer_name are 127.0.0.1, black list seems not working.
If large requests sent from the plugin server, ss-server would in DoS.
Maybe when in plugin mode, disable black list in ss-server and move it to plugin server?