In the following method it is possible to run into a segmentation fault (commit 1451d9b92452a0cfa0be64ec298cba42cd5ed818):

2279 static void printIPv4Addresses(uint16_t portInHostOrder) {
2280     struct ifaddrs* addrs = NULL;
2281     getifaddrs(&addrs);
2282     struct ifaddrs* p = addrs;
2283     while (NULL != p) {
2284         if (p->ifa_addr->sa_family == AF_INET) {
2285             char hostname[256];
2286             getnameinfo(p->ifa_addr, sizeof(struct sockaddr_in), hostname, sizeof(hostname), NULL, 0, NI_NUMERICHOST);
2287             ews_printf("Probably listening on http://%s:%u\n", hostname, portInHostOrder);
2288         }
2289         p = p->ifa_next;
2290     }
2291     if (NULL != addrs) {
2292         freeifaddrs(addrs);
2293     }
2294 }

After calling getifaddrs() it is possible that p->ifa_addr == NULL as per the documentation http://man7.org/linux/man-pages/man3/getifaddrs.3.html :

The ifa_addr field points to a structure containing the interface address. (The sa_family subfield should be consulted to determine the format of the address structure.) This field may contain a null pointer.

As the following code relies on the pointer not being NULL and this method having no impact on the actual functionality of the server itself, I suggest a patch as follows:

From fddf18dab7cb938f9d3fc6b0751d90866d2de4b3 Mon Sep 17 00:00:00 2001
From: Dan <[email protected]>
Date: Sun, 24 Mar 2019 01:08:25 +1300
Subject: [PATCH] Check for NULL pointer after calling getifaddrs()

---
 EmbeddableWebServer.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmbeddableWebServer.h b/EmbeddableWebServer.h
index 129548b..febf093 100755
--- a/EmbeddableWebServer.h
+++ b/EmbeddableWebServer.h
@@ -2281,7 +2281,7 @@ static void printIPv4Addresses(uint16_t portInHostOrder) {
     getifaddrs(&addrs);
     struct ifaddrs* p = addrs;
     while (NULL != p) {
-        if (p->ifa_addr->sa_family == AF_INET) {
+        if (p->ifa_addr != NULL && p->ifa_addr->sa_family == AF_INET) {
             char hostname[256];
             getnameinfo(p->ifa_addr, sizeof(struct sockaddr_in), hostname, sizeof(hostname), NULL, 0, NI_NUMERICHOST);
             ews_printf("Probably listening on http://%s:%u\n", hostname, portInHostOrder);
-- 
2.17.1

P.S. Thanks for this awesome project, we are using it as part of a local debug server for a humanoid robotics project: https://www.humanoid.science/

Hi @hellerf, thanks again for the great work.

I'd like to ask you if you could look at those commits. Basically it adds support for:

• some msys2 flavors by declaring strcasecmp not as a function but a macro (because the function may or may not be defined). This may be possibly also ifdef-decided guarded macro or function but I think that this one is easier.
• completely disable pthread-compat stuff if winpthreads are used

Those two are fundamental for me in order to use your upstream, because otherwise it triggers compilation error in my project. I guess that it should not harm other builds, since it is if-defed.

If you decide to merge, I'd perhaps have a batch of small fixes to merge.

Thanks for your time! Martin

Hi, developers, thank you for your checking. I found a possible bug in UltraGrid, which locates in EmbeddableWebServer. It seems the lock server is not released correctly when!server->initialize in the function serverStop?

https://github.com/CESNET/UltraGrid/blob/e3c926c8ff67586bf74c4cc0763a78c83ede9cf6/src/EmbeddableWebServer.h#L1515-L1526 Can you confirm this?

The original issue: https://github.com/CESNET/UltraGrid/issues/183

Several functions like responseAllocHTMLWithStatus() are ignoring the status code parameter and always using 200. This is breaking functions like responseAlloc404NotFoundHTML(). The browser always gets 200 OK rather than the actual response code.

• removal of whitespaces at the end of a line.
• indentation (little bit)

Fix for warnings under MinGW64:

• the socket (DWORD) was compare to -1, should be vs INVALID_SOCKET
• a few of the parameters of the pthread-wrapper weren't used, mark them as unused so there ain't no warnings.
• SIGPIPEHandler was not used, and as it was a static, it spawned a warning about an unused function
• return type for connectionHandlerThread was a NULL casted, should be a 0
• conversion from GetLastError to %d caused a warning. Now bring it first to a DWORD always to mitigate the warning.

Hi, developers, I have a suggestion about error handlings for locking. Would it be better to handle the possible errors that return from pthread_mutex_lock.

Possible situations that return errors.

    EAGAIN The mutex could not be acquired because the maximum number
              of recursive locks for mutex has been exceeded.

       EINVAL The mutex was created with the protocol attribute having
              the value PTHREAD_PRIO_PROTECT and the calling thread's
              priority is higher than the mutex's current priority
              ceiling.

       ENOTRECOVERABLE
              The state protected by the mutex is not recoverable.

       EOWNERDEAD
              The mutex is a robust mutex and the process containing the
              previous owning thread terminated while holding the mutex
              lock. The mutex lock shall be acquired by the calling
              thread and it is up to the new owner to make the state
              consistent.

       EDEADLK
              The mutex type is PTHREAD_MUTEX_ERRORCHECK and the current
              thread already owns the mutex.

       EOWNERDEAD
              The mutex is a robust mutex and the previous owning thread
              terminated while holding the mutex lock. The mutex lock
              shall be acquired by the calling thread and it is up to
              the new owner to make the state consistent.

       EDEADLK
              A deadlock condition was detected.

https://github.com/hellerf/EmbeddableWebServer/blob/9d71cee513e2eae98d1676b554385c7e894096db/EmbeddableWebServer.h#L1920-L1922

For example, this example does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program (CWE-413). The manners of error handlings could be flagging any warnings or returning before accessing the critical region.

void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);

/* access shared resource */


pthread_mutex_unlock(mutex);
}

I think I need to add a "Access-Control-Allow-Origin: *" header to my response. I could not see how to add headers.

When I tried it here: struct Response* responseAllocWithFile(const char* filename, const char* MIMETypeOrNULL) { struct Response* response = responseAlloc(200, "OK", MIMETypeOrNULL, 0); response->extraHeaders = strdup("Access-Control-Allow-Origin: *"); response->filenameToSend = strdup(filename); return response; }

I broke an already working (in browser with security disabled) json file response.

I really do not understand CORS that much and why when I have a server, the origins do not match. Maybe its a windows thing.

Previously I used the AFL fuzzer on Linux to catch bugs. It seems like Travis CI can run AFL! I ran AFL for several days. I don't think it's nice to tie up infrastructure for several days fuzzing the EmbeddableWebServer. But it's certainly something to look into. Example: https://github.com/awslabs/s2n/pull/263/files

To be implemented after Part 1

x. Run unit tests (these already exist) x. Make examples in the README build as part of the CI x. Create integration tests to do end-to-end response / request testing x. Do stress testing with abench