Hi Wim, all, 2011/3/16 Wim Dumon <[email protected]>: > We've run Wt on uClibc on several occasions without encountering this > problem, so I'm interested in what goes wrong.
What uClibc version and config do you use? How was the system built? I'm using Buildroot 2011.02 with it's default config for uClibc 0.9.31.x (http://git.buildroot.net/buildroot/tree/toolchain/uClibc/uClibc-0.9.31.config). After debugging hello.wt with the uClibc toolchain I switched to a glibc toolchain (CodeSourcery Lite 2010.09-50 for ARM). The Wt examples run just fine with that. However, I'd like to find and fix the bug. I think it is possible that the bug is in Wt, but triggered by something in uClibc (maybe configuration variations or different versions), so the rest of this email is what I've found while debugging hello.wt with the uClibc toolchain. First, the error: # hello.wt --docroot . --http-address 0.0.0.0 --http-port 8080 Reading: /etc/wt/wt_config.xml [1999-Dec-31 17:29:41.389758] 1129 - [notice] "Wt: initializing built-in httpd" [1999-Dec-31 17:29:41.395503] 1129 - [notice] "Reading Wt config file: /etc/wt/wt_config.xml (location = 'hello.wt')" [1999-Dec-31 17:29:41.422544] 1129 - [notice] "Started server: http://0.0.0.0:8080"; remote_endpoint() threw: Bad file descriptor terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error>' what(): Bad file descriptor Aborted The code that throws the exceptions is located in <wt>/src/http/Connection.C: 50 void Connection::start() 51 { 52 request_parser_.reset(); 53 request_.reset(); 54 try { 55 request_.remoteIP = socket().remote_endpoint().address().to_string(); 56 } catch (std::exception& e) { 57 std::cerr << "remote_endpoint() threw: " << e.what() << std::endl; 58 } 59 60 socket().set_option(asio::ip::tcp::no_delay(true)); 61 62 startAsyncReadRequest(buffer_, CONNECTION_TIMEOUT); 63 } Both line 55 and 60 throw exceptions (Bad file descriptor), but the last exception is uncaught and kills the program. I did 'call socket()' in gdb (when in the code above). Amongst the returned data I found: implementation = {<boost::asio::detail::reactive_socket_service_base::base_implementation_type> = {socket_ = -1, state_ = 0 '\000', reactor_data_ = 0x20202020}, protocol_ = { It seems like socket() is working on an invalid socket fd ("socket_ = -1" above). That explains the exception(s). But why doesn't socket() return a valid socket fd, like it does when built with glibc? I thought maybe boost.asio was to blame, so I built a boost asio server example[2]. It runs just fine with uClibc and gdb shows that 'call socket()' returns a valid fd. Is there a missing error check in Wt where socket() is opened? (I tried to find the place where socket() is opened myself, but Wt uses multiple threads and when I "set scheduler-locking on" in gdb, to prevent other threads from run freely, gdb just freezes. I also failed at locating it with static code analysis. Hints appreciated.) [1]: http://stackoverflow.com/questions/5085162/bad-file-descriptor-error-when-setting-non-blocking-on-a-boostasioiptcpso [2]: http://www.boost.org/doc/libs/1_46_1/doc/html/boost_asio/example/allocation/server.cpp Best regards, Bjørn Forsman ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
