Tracking Down Nasty Boost ASIO Core Dump
This afternoon I noticed that I was having a nasty, intermittent core dump on the client code for my request/response greek service. It didn't happen all the time, and it was always something in the boost ASIO code, and that required that I start digging into that code once again to see what I didn't shut down properly. It has to be one of the threads that are started in the client, and I'm just not shutting it down before bailing on the app, and then there's a thread with nothing to act on. Bam!
So I started digging and while I could require that users of the client call close() before quitting, I don't really like that limitation. I want to make code that's as robust as possible so if the client is a stack variable, and it goes out of scope for any reason, it shuts things down cleanly, and there's no reason to hassle with any shut-down code.
Unfortunately, I hadn't done a lot of that in the base client code. It worked, and my tests hadn't shown an issue, but this particular subclass was just fast enough, or just something enough to cause a timing problem, and about once every ten times, it'd core dump on the exit. Annoying.
So I put in some more shutdown code in the base class. These didn't effect the behavior of the class, it was just a lot more explicit about shutting down the connect and the channel when it needed to. It probably didn't amount to more than 15 lines of code in the base class. But an important 15 lines.
Looks better now.
[6/7 5:30pm] UPDATE: Added one more thing - it seems that I still get the problem after hours. Why? No idea, but it dawned on me that in my destructor for the client class, I'm stopping the boost ASIO io_service thread. And if I'm faster than the stoppage, I'll get into trouble. So I added in a simple join() on that thread after telling it to die, and that made things much better after-hours. Good.