Simple Listener Program Faulting on Linux

Jun 5, 2014 at 8:58 PM
Edited Jun 10, 2014 at 12:54 PM
The following program is faulting on Linux (Ubuntu 14 and RHEL 7) on listener.close. It faults if one or more requests are processed, not on zero requests. It actually serves up pages just fine, it just faults on close or end of program. I suspect the issue is threading due to wrong build or LD_LIBRARY_PATH. Can someone spot the error?
g++ t.cpp -std=c++11 -I ../../casablanca/Release/include -L ../../casablanca/Release/build.release/Binaries -lcasablanca 
export LD_LIBRARY_PATH=../../casablanca/Release/build.release/Binaries
./a.out
#include "cpprest/http_client.h"
#include "cpprest/http_listener.h"

int main()
{
    try
    {
        web::http::experimental::listener::http_listener listener(U("http://192.168.1.111:3901"));
        listener.support([&] (web::http::http_request request) { request.reply(web::http::status_codes::OK, U("Hello, World!")); });
        listener.open().wait();
        std::cout << "waiting for input" << std::endl;
        std::string line;
        std::getline(std::cin, line);
        std::cout << "closing" << std::endl;
        listener.close(); // .wait();
    }
    catch (...)
    {
        std::cout << "caught error" << std::endl;
    }
    return(0);
}
Coordinator
Jun 5, 2014 at 9:08 PM
Hi BSalita,

Quickly looking at your code I notice you are not waiting on the listener.close() operation to complete. This function is asynchronous and the close won't be finished before you start exiting the program. This definitely can cause problems. Can you try adding a ".wait();" to that close operation and do you still get issues?

Please note I didn't actually try running your code you have here.

Thanks,
Steve
Jun 6, 2014 at 8:30 AM
Edited Jun 10, 2014 at 12:55 PM
I tried with and without wait() before posting. With close().wait(), the program hangs forever. So I guess the problem is in close()?

I'm surprised that there's nothing obviously wrong. All the casablanca tests pass. I figured I was missing something in the gcc build line or incorrect LD_LIBRARY_PATH. If you can't spot anything on a second look, can you try to dup issue on your system? It's hard to believe this is a casablanca issue. Maybe a Boost version issue? Also I'm running in VirtualBox so that's an added possibility.

edit: inserted port 3901 in end point. same issue.
edit: inserted & in lamda. same issue
Jun 10, 2014 at 1:05 PM
Edited Jun 11, 2014 at 3:34 PM
Some interesting findings on Linux. I'm not sure what it means.

If I use curl, the program displays "Hello World!' and can terminate normally. Works 100% of time.
> curl "http://192.168.1.111:3901"
Hello World!
If I type "http://192.168.1.111:3901" as the url in IE, Chrome or FireFox, the program faults on close() or hangs forever on wait(). Sometimes I get an http exception "Trying to send multiple responses to an http request"

Edit: IE is now behaving like Chrome or Firefox.
Edit: Sometimes getting http exception "Trying to send multiple responses to an http request"
Jun 13, 2014 at 4:17 PM
I'm blocked on this issue. Same issue with the new 2.1 version. Always works on Windows and never works on Ubuntu 14.04 or RHEL 7. This appears to be a bug. Maybe it's one of the previously reported issues; a race condition on close, or the single core issue. I dunno. I'm trying to turn over my project to my customer but this issue is holding me up.
Coordinator
Jun 13, 2014 at 6:54 PM
Edited Jun 13, 2014 at 6:58 PM
Hi BSalita,

I am able to repro the issue. listener.close().wait() hangs once the listener has responded to some requests coming from a browser.

Now that we have a repro, we will investigate this further. Thank you for your patience and help in narrowing down the steps to reproduce the issue!

This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.

Thanks
Kavya
Jun 13, 2014 at 7:27 PM
Oh, thank God. I've spent 4 man-days trying to figure it out. It's such an incredibly simple program that I couldn't imagine I had found a bug. I'm curious what the program does differently when so many other tests have passed. To compound the confusion, curl always works but all browsers fail. I'll bet someone on the team will instantly know the problem based on curl working but not browsers.

For perspective, I don't think we have any other open issues with the C++ Rest SDK. Yes, I'm looking forward to some features such as HTTPS listener on Linux but that doesn't block our work -- at least not for months.
Jun 14, 2014 at 9:05 PM
Edited Jun 15, 2014 at 11:19 AM
Oh, oh. Identical hang on Windows v2.1. Didn't happen on Windows v2.01. Happens using curl too. This is a weird twist. I'll look into this further after a night's sleep.

Update 15-Jun-2014: Created new thread to discuss issue v2.1 Breaks http_request Queuing
Jul 2, 2014 at 11:13 AM
I can confirm that the current developer branch has fixed this issue. I tested on RHEL 7. Also run_tests.sh shows all casablanca tests have passed. Thanks for the fix!