exit(3) hangs in Linux C++ - c++

Question

I have a small C++ program that pings other machines on a network and send status information out over another network. The program runs as a daemon, so the startup process forks off a child and then calls exit. This program is cross-compiled to run on two different architectures: x86 and ARM. The GCC versions are 4.4 and 3.5 respectively. I can compile and run the program on x86 and it works flawlessly. However, when I run the program on the ARM, it hangs any time I call exit, not just after the fork. I have no functions registered with atexit or on_exit. The following are my includes:
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <sstream>
#include <string>
#include <set>
#include <vector>
#include <boost/bind.hpp>
#include <boost/asio.hpp>
#include <boost/thread.hpp>
#include "telnet_client.h"
#include <stdint.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/select.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/time.h>
#include <netdb.h>
#include <net/if.h>
#include <sys/ioctl.h>
#include <unistd.h>
#include <syslog.h>
#include <customlib1.h>
#include <customlib2.h>
The following are my GCC commands:
arm-none-linux-gnueabi-g++ -Wall -DBUILDSTAMP="\"`date '+%F %T'`\"" -g -ggdb -O0 -I/usr/local/arm/arm-2007q1/arm-none-linux-gnueabi/libc/usr/include -DEMBEST_ARM -I/usr/local/share/arm/boost/src -I../include/ -I../include_rms -c can_wifid.cpp -o can_wifid.o
arm-none-linux-gnueabi-g++ -Wall -DBUILDSTAMP="\"`date '+%F %T'`\"" -g -ggdb -O0 -I/usr/local/arm/arm-2007q1/arm-none-linux-gnueabi/libc/usr/include -DEMBEST_ARM -I/usr/local/share/arm/boost/src -I../include/ -I../include_rms -c telnet_client.cpp -o telnet_client.o
arm-none-linux-gnueabi-g++ -Wall -DBUILDSTAMP="\"`date '+%F %T'`\"" -g -ggdb -O0 -I/usr/local/arm/arm-2007q1/arm-none-linux-gnueabi/libc/usr/include -DEMBEST_ARM -I/usr/local/share/arm/boost/src can_wifid.o telnet_client.o -L/usr/local/arm/arm-2007q1/arm-none-linux-gnueabi/libc/usr/lib -L../lib_embest_arm -L../lib_rms_embest_arm -Wl,-Bdynamic -lutilities -lboost_system -lboost_thread -lcanprovider -lembestcan -o can_wifid
Even just parsing my command line parameters with getopt then calling exit after a version message causes this problem (simplest case in my program). Has anybody ever experienced anything like this where exit just hangs ?
EDIT: Added code for the first part of the main function:
struct canwifid_options
{
public:
bool daemon_mode;
int verbosity;
canwifid_options()
{
this->daemon_mode = false;
this->verbosity = LOG_NOTICE;
}
};
static canwifid_options options;
int main(int argc, char * argv[])
{
int LoggingOptions = LOG_CONS|LOG_NDELAY|LOG_PID;
pid_t Pid;
ParseCommandLine(argc, argv);
if (!options.daemon_mode)
{
LoggingOptions |= LOG_PERROR;
}
openlog("can_wifid", LoggingOptions, LOG_USER);
setlogmask(LOG_UPTO(options.verbosity));
if (options.daemon_mode)
{
Pid = fork();
if (Pid < 0)
{
// couldn't fork off and create a child process
// log it, %m is a special syslog flag
syslog(LOG_CRIT, "Unable to create daemon [Error: %m]");
exit(ESRCH);
}
else if (Pid > 0)
{
// we're the parent, so we're done and out of here
exit(EXIT_SUCCESS);
}
else
{
// we're the child, take control of the session.
setsid();
// change to the root directory so we don't retain unnecessary control
// of any mounted volumes
chdir("/");
// clear our file mode creation mask
umask(0000);
}
}
else
{
// get our process ID
Pid = getpid();
}
syslog(LOG_INFO, "Running as %s", options.daemon_mode ? "daemon" : "standalone");
// Network code here, snipped for clarity
}
And there ParseCommandLine function:
static void ParseCommandLine(int argc, char *argv[])
{
int c;
while ((c = getopt(argc, argv, "dhqvDV?")) > 0)
{
switch (c)
{
case 'd':
options.daemon_mode = true;
break;
case 'V':
VersionMessage(argv);
exit(EXIT_SUCCESS);
break;
case 'q':
options.verbosity = LOG_WARNING;
break;
case 'v':
options.verbosity = LOG_INFO;
break;
case 'D':
options.verbosity = LOG_DEBUG;
break;
case 'h':
case '?':
default:
HelpMessage(argv);
exit(EXIT_SUCCESS);
break;
}
}
return; //done
}

Answer 1

An issue I ran into once is that calling exit attempts to exit and calls global destructors WITHOUT trying to unwind the stack or call any destructors for local objects on the stack. This can easily manifest if you have any sort of locks that might be required for global destructors. For example, this program deadlocks in exit (actually in the global dtor):
#include <iostream>
#include <mutex>
std::mutex lock;
class A {
public:
A() {
std::lock_guard<std::mutex> acquire(lock);
std::cout << "ctor A" << std::endl;
}
~A() {
std::lock_guard<std::mutex> acquire(lock);
std::cout << "dtor A" << std::endl;
}
};
A a;
int main()
{
std::lock_guard<std::mutex> acquire(lock);
exit(0);
}
Now your problem may be something completely different, but there's a strong possibility its related to something in a global destructor that is misbehaving because some object on the stack has not been destroyed properly.
If you want to exit while unwinding the stack properly (which is required for RAII structured code), you can't call exit. Instead you need to throw an exception which is caught (only) in main and causes main to return.