How much of a file has been read - c++

I have a program which reads a 10 MByte file and processes the data as the data is being read in 4K chunks. The test usually takes 1 min - 2 min. But there are some instances when the program takes more than 10 min, at which point the test it killed and a core is generated. Following is the code that reads the file:
string filename("data.out");
ifstream ifs;
vector<char> buf(4096);
ifs.open(filename, ios::in | ios::binary);
if (!ifs.is_open()) {
cout << "ERROR : " << filename << "can't be opened." << endl;
VERIFY(ifs.is_open());
}
while (!ifs.eof()) {
ifs.read(buf.data(), buf.size()); <======== Line 1
process_data (buf.data(), ifs.gcount()); <======== Line 2
}
ifs.close();
I have two cores that show the program is stuck at Line 1 and Line 2.
Top of bt of core1 at Line 1:
#0 0x00007f942a462175 in std::istream::read (this=0x7fff4ce69de0,
__s=0x9120000 "\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324\324"..., __n=4096) at /home/packages/gcc/4.7/w/gcc-4.7-4.7.2/build/x86_64-linux-gnu/libstdc++-v3/include/bits/istream.tcc:651
Top of bt of core2 at Line 2:
#0 0x00000000004375f3 in std::__addressof<char> (__r=#0x7fa3176391a6: -128 '\200') at /usr/include/c++/4.7/bits/move.h:47
#1 0x0000000000436cd4 in std::vector<char, std::allocator<char> >::data (this=0x7fff346ad770)
at /usr/include/c++/4.7/bits/stl_vector.h:859
Initially, from core1, I thought the issue was with ifs.read() taking a long time. But after the second core, I am thinking the issue might be related to vector::data().
Is there a way I can tell if any part of the file has been read, by inspecting certain fields (e.g file offset) stored in ifstream.
I don't like posting dump of large structure, but here it is if someone can shed some light how I can figure out from this dump how much of the 10MB has been read.
(gdb) p ifs
$3 = warning: can't find linker symbol for virtual table for `std::basic_ifstream<char, std::char_traits<char> >' value
{
<std::basic_istream<char, std::char_traits<char> >> = {
<std::basic_ios<char, std::char_traits<char> >> = {
<std::ios_base> = {
_vptr.ios_base = 0xfbfcc0,
static boolalpha = std::_S_boolalpha,
static dec = std::_S_dec,
static fixed = std::_S_fixed,
static hex = std::_S_hex,
static internal = std::_S_internal,
static left = std::_S_left,
static oct = std::_S_oct,
static right = std::_S_right,
static scientific = std::_S_scientific,
static showbase = std::_S_showbase,
static showpoint = std::_S_showpoint,
static showpos = std::_S_showpos,
static skipws = std::_S_skipws,
static unitbuf = std::_S_unitbuf,
static uppercase = std::_S_uppercase,
static adjustfield = std::_S_adjustfield,
static basefield = std::_S_basefield,
static floatfield = std::_S_floatfield,
static badbit = std::_S_badbit,
static eofbit = std::_S_eofbit,
static failbit = std::_S_failbit,
static goodbit = std::_S_goodbit,
static app = std::_S_app,
static ate = std::_S_ate,
static binary = std::_S_bin,
static in = std::_S_in,
static out = std::_S_out,
static trunc = std::_S_trunc,
static beg = std::_S_beg,
static cur = std::_S_cur,
static end = std::_S_end,
_M_precision = 6,
_M_width = 0,
_M_flags = 4098,
_M_exception = std::_S_goodbit,
_M_streambuf_state = 5,
_M_callbacks = 0x0,
_M_word_zero = {
_M_pword = 0x0,
_M_iword = 0
},
_M_local_word = {{
_M_pword = 0x0,
_M_iword = 0
}, {
_M_pword = 0x0,
_M_iword = 0
}, {
_M_pword = 0x0,
_M_iword = 0
}, {
_M_pword = 0x0,
_M_iword = 0
}, {
_M_pword = 0x0,
_M_iword = 0
}, {
_M_pword = 0x0,
_M_iword = 0
}, {
_M_pword = 0x0,
_M_iword = 0
}, {
_M_pword = 0x0,
_M_iword = 0
}},
_M_word_size = 8,
_M_word = 0x7fff4ce69f20,
_M_ios_locale = {
static none = 0,
static ctype = 1,
static numeric = 2,
static collate = 4,
static time = 8,
static monetary = 16,
static messages = 32,
static all = 63,
_M_impl = 0x7f942a6e3aa0,
static _S_classic = 0x7f942a6e3aa0,
static _S_global = 0x7f942a6e3aa0,
static _S_categories = 0x7f942a6c86a0,
static _S_once = 2
}
},
members of std::basic_ios<char, std::char_traits<char> >:
_M_tie = 0x0,
_M_fill = 0 '\000',
_M_fill_init = false,
_M_streambuf = 0x7fff4ce69df0,
_M_ctype = 0x7f942a6e3d20,
_M_num_put = 0x7f942a6e4040,
_M_num_get = 0x7f942a6e4030
},
members of std::basic_istream<char, std::char_traits<char> >:
_vptr.basic_istream = 0xfbfc98,
_M_gcount = 0
},
members of std::basic_ifstream<char, std::char_traits<char> >:
_M_filebuf = warning: can't find linker symbol for virtual table for `std::basic_filebuf<char, std::char_traits<char> >' value
{
<std::basic_streambuf<char, std::char_traits<char> >> = {
_vptr.basic_streambuf = 0xfc0a70,
_M_in_beg = 0x6306000 "\317\317\317\......320\320\320\320"...,
_M_in_cur = 0x6307fff "",
_M_in_end = 0x6307fff "",
_M_out_beg = 0x0,
_M_out_cur = 0x0,
_M_out_end = 0x0,
_M_buf_locale = {
static none = 0,
static ctype = 1,
static numeric = 2,
static collate = 4,
static time = 8,
static monetary = 16,
static messages = 32,
static all = 63,
_M_impl = 0x7f942a6e3aa0,
static _S_classic = 0x7f942a6e3aa0,
static _S_global = 0x7f942a6e3aa0,
static _S_categories = 0x7f942a6c86a0,
static _S_once = 2
}
},
members of std::basic_filebuf<char, std::char_traits<char> >:
_M_lock = {
__data = {
__lock = 0,
__count = 0,
__owner = 0,
__nusers = 0,
__kind = 0,
__spins = 0,
__list = {
__prev = 0x0,
__next = 0x0
}
},
__size = '\000' <repeats 39 times>,
__align = 0
},
_M_file = {
_M_cfile = 0x70186c0,
_M_cfile_created = true
},
_M_mode = 12,
_M_state_beg = {
__count = 0,
__value = {
__wch = 0,
__wchb = "\000\000\000"
}
},
_M_state_cur = {
__count = 0,
__value = {
__wch = 0,
__wchb = "\000\000\000"
}
},
_M_state_last = {
__count = 0,
__value = {
__wch = 0,
__wchb = "\000\000\000"
}
},
_M_buf = 0x6306000 "\317\317\317\317\317\......320\320\320\320\320"...,
_M_buf_size = 8192,
_M_buf_allocated = true,
_M_reading = true,
_M_writing = false,
_M_pback = 0 '\000',
_M_pback_cur_save = 0x0,
_M_pback_end_save = 0x0,
_M_pback_init = false,
_M_codecvt = 0x7f942a6e3f60,
_M_ext_buf = 0x0,
_M_ext_buf_size = 0,
_M_ext_next = 0x0,
_M_ext_end = 0x0
}
}
(gdb)
Thank you,
Ahmed.

Do not loop on eof.
while (ifs.read(buf.data(), buf.size())) {
size_t read = ifs.gcount();
if(read==0) break; // don't trust passing `0` to `process_data`:
process_data(buf.data(), read);
if (read<buf.size()) break; // if we finished, end.
}
Finding the end of input is best done by attempting io, and noticing something went wrong. In this case, we read, count how many bytes we read, and when we read 0 bytes or have read fewer bytes than we expected to read, we decide there isn't any more data to come.
We also end if any failbit has been set on ifs by the IO operation.

Related

vkQueueSubmit blocks when using timeline semaphores

I need to run a function on CPU between two GPU batches. For this I use timeline semaphores. As far as I know, vkQueueSubmit does not block. However, it blocks when I submit these GPU batches:
uint64_t host_wait = timeline;
uint64_t host_signal = ++timeline;
uint64_t wait0 = timeline;
uint64_t signal0 = ++timeline;
uint64_t wait1 = timeline;
uint64_t signal1 = ++timeline;
VkPipelineStageFlags wait_mask = VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT;
VkTimelineSemaphoreSubmitInfo sp_submit0 = {
.sType = VK_STRUCTURE_TYPE_TIMELINE_SEMAPHORE_SUBMIT_INFO,
.waitSemaphoreValueCount = 1,
.pWaitSemaphoreValues = &wait0,
.signalSemaphoreValueCount = 1,
.pSignalSemaphoreValues = &signal0,
};
VkSubmitInfo submit0 = {
.sType = VK_STRUCTURE_TYPE_SUBMIT_INFO,
.pNext = &sp_submit0,
.waitSemaphoreCount = 1,
.pWaitSemaphores = &timeline_semaphore,
.pWaitDstStageMask = &wait_mask,
.signalSemaphoreCount = 1,
.pSignalSemaphores = &timeline_semaphore,
};
VkTimelineSemaphoreSubmitInfo sp_submit1 = {
.sType = VK_STRUCTURE_TYPE_TIMELINE_SEMAPHORE_SUBMIT_INFO,
.waitSemaphoreValueCount = 1,
.pWaitSemaphoreValues = &wait1,
.signalSemaphoreValueCount = 1,
.pSignalSemaphoreValues = &signal1,
};
VkSubmitInfo submit1 = {
.sType = VK_STRUCTURE_TYPE_SUBMIT_INFO,
.pNext = &sp_submit1,
.waitSemaphoreCount = 1,
.pWaitSemaphores = &timeline_semaphore,
.pWaitDstStageMask = &wait_mask,
.commandBufferCount = 1,
.pCommandBuffers = &command_buffer,
.signalSemaphoreCount = 1,
.pSignalSemaphores = &timeline_semaphore,
};
VkSubmitInfo infos[2] = { submit0, submit1 };
vkQueueSubmit(queue, 2, infos, fence);
// here vkQueueSubmit blocks the thread
WaitSemaphore(timeline_semaphore, host_wait);
some_function();
SignalSemaphore(timeline_semaphore, host_signal);
It is blocking for seconds without return, I think this is something like a deadlock. In the debugger, I saw SleepEx function call from vkQueueSubmit: vk_icdGetInstanceProcAddrSG -> ... -> SleepEx.
But vkQueueSubmit does not block in this sample (combined batch):
uint64_t host_wait = timeline;
uint64_t host_signal = ++timeline;
uint64_t wait1 = timeline;
uint64_t signal1 = ++timeline;
VkPipelineStageFlags wait_mask = VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT;
VkTimelineSemaphoreSubmitInfo sp_submit1 = {
.sType = VK_STRUCTURE_TYPE_TIMELINE_SEMAPHORE_SUBMIT_INFO,
.waitSemaphoreValueCount = 1,
.pWaitSemaphoreValues = &wait1,
.signalSemaphoreValueCount = 1,
.pSignalSemaphoreValues = &signal1,
};
VkSubmitInfo submit1 = {
.sType = VK_STRUCTURE_TYPE_SUBMIT_INFO,
.pNext = &sp_submit1,
.waitSemaphoreCount = 1,
.pWaitSemaphores = &timeline_semaphore,
.pWaitDstStageMask = &wait_mask,
.commandBufferCount = 1,
.pCommandBuffers = &command_buffer,
.signalSemaphoreCount = 1,
.pSignalSemaphores = &timeline_semaphore,
};
VkSubmitInfo infos[1] = { submit1 };
vkQueueSubmit(queue, 1, infos, fence);
WaitSemaphore(timeline_semaphore, host_wait);
some_function();
SignalSemaphore(timeline_semaphore, host_signal);
Why vkQueueSubmit blocks in the first code sample? What are the possible causes of this problem?
I use Vulkan 1.2 (SDK 1.2.135) on Windows 10 and Radeon RX 570 (driver 20.4.2).
EDIT: When I add a command buffer to submit0, vkQueueSubmit will not block. Is it a bug in the driver?
Doing something odd like submitting a batch with no work is far more likely to be the cause.
The spec doesn’t have performance requirements. The fact that something is legal does not make it a good idea. Broadly speaking, if there are two ways to do a thing, do it the obvious way. And sending an empty batch isn’t exactly obvious
https://community.khronos.org/t/vkqueuesubmit-blocks-when-using-timeline-semaphores/105704/2

the content of pointer changed when passed to the function

I am using C++ to do my work. The following is the problem I am confulsed.
typedef struct netHandler {
int m_iFd;
poll_event_t* m_pPollEvent;
epoll_event m_Event;
void* m_pConn;
} netHandler_t;
Here is my struct. When the program running. I set a breakpoint in the following place:
connection_t* conn = geneConnection(idenfication, fd, handler);
And before step into this funcition, I record the handler's content.
p *(netHandler_t *) 0x2aaaac000960
$2 = {m_iFd = 9, m_pPollEvent = 0x2aaaac000930, m_Event =
{events = 1, data = {ptr = 0x2aaaac000960, fd = -1409283744, u32 = 2885683552, u64 = 46912518490464}},
m_pConn = 0x60d010}
Then I step into the geneConnection function. The content changed.
p *(netHandler_t *) 0x2aaaac000960
$3 = {m_iFd = 9, m_pPollEvent = 0xac00093000000000, m_Event =
{events = 10922, data = {ptr = 0xac00096000000001, fd = 1, u32 = 1, u64 = 12393916482445115393}},
m_pConn = 0x2aaa}
That's like the struct was shrifted.
connection_t* geneConnection(long iden, int sendfd, netHandler_t* handler);
This is the declare of geneConnection. I don't understand why this happened. When I change this function to inline type. The content of handler would not changed.

Byte layout of a struct in C vs. C++

I need to write a struct to a filedescriptor. I have code in C that works, however when I try to create a struct of the same layout in memory, the result is different.
In C, the struct is initialized using designated initializers. In C++, in the header file I am defining the structure and initialize every member in an init function in the implementation.
Below are both code snippets. Thank you!
struct in C:
static const struct {
struct usb_functionfs_descs_head header;
struct {
struct usb_interface_descriptor intf;
struct usb_endpoint_descriptor_no_audio sink;
struct usb_endpoint_descriptor_no_audio source;
} __attribute__((packed)) fs_descs, hs_descs;
} __attribute__((packed)) descriptors = {
.header = {
.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC),
.length = cpu_to_le32(sizeof descriptors),
.fs_count = 3,
.hs_count = 3,
},
.fs_descs = {
.intf = {
.bLength = sizeof descriptors.fs_descs.intf,
.bDescriptorType = USB_DT_INTERFACE,
.bNumEndpoints = 2,
.bInterfaceClass = USB_CLASS_VENDOR_SPEC,
.iInterface = 1,
},
.sink = {
.bLength = sizeof descriptors.fs_descs.sink,
.bDescriptorType = USB_DT_ENDPOINT,
.bEndpointAddress = 1 | USB_DIR_IN,
.bmAttributes = USB_ENDPOINT_XFER_BULK,
/* .wMaxPacketSize = autoconfiguration (kernel) */
},
.source = {
.bLength = sizeof descriptors.fs_descs.source,
.bDescriptorType = USB_DT_ENDPOINT,
.bEndpointAddress = 2 | USB_DIR_OUT,
.bmAttributes = USB_ENDPOINT_XFER_BULK,
/* .wMaxPacketSize = autoconfiguration (kernel) */
},
},
.hs_descs = {
.intf = {
.bLength = sizeof descriptors.fs_descs.intf,
.bDescriptorType = USB_DT_INTERFACE,
.bNumEndpoints = 2,
.bInterfaceClass = USB_CLASS_VENDOR_SPEC,
.iInterface = 1,
},
.sink = {
.bLength = sizeof descriptors.hs_descs.sink,
.bDescriptorType = USB_DT_ENDPOINT,
.bEndpointAddress = 1 | USB_DIR_IN,
.bmAttributes = USB_ENDPOINT_XFER_BULK,
.wMaxPacketSize = cpu_to_le16(512),
},
.source = {
.bLength = sizeof descriptors.hs_descs.source,
.bDescriptorType = USB_DT_ENDPOINT,
.bEndpointAddress = 2 | USB_DIR_OUT,
.bmAttributes = USB_ENDPOINT_XFER_BULK,
.wMaxPacketSize = cpu_to_le16(512),
.bInterval = 1, /* NAK every 1 uframe */
},
},
};
In c++ header file:
struct stDescriptorBody {
usb_interface_descriptor source_sink_intf;
usb_endpoint_descriptor_no_audio sink;
usb_endpoint_descriptor_no_audio source;
};__attribute__((packed))
struct stDescriptor {
usb_functionfs_descs_head header;
stDescriptorBody fs_descs;
stDescriptorBody hs_descs;
}__attribute__((packed)) ;
init function in implementation file:
stDescriptor initdescriptor(){
stDescriptor descriptor;
descriptor.header.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC);
descriptor.header.length = cpu_to_le32(sizeof descriptor);
descriptor.header.fs_count = 2;
descriptor.header.hs_count = 2;
descriptor.fs_descs.source_sink_intf.bLength = sizeof descriptor.fs_descs.source_sink_intf;
descriptor.fs_descs.source_sink_intf.bDescriptorType = USB_DT_INTERFACE;
descriptor.fs_descs.source_sink_intf.bNumEndpoints = 2;
descriptor.fs_descs.source_sink_intf.bInterfaceClass = USB_CLASS_VENDOR_SPEC;
descriptor.fs_descs.source_sink_intf.iInterface = 1;
descriptor.fs_descs.source.bDescriptorType = USB_DT_ENDPOINT;
descriptor.fs_descs.source.bEndpointAddress = 1 | USB_DIR_OUT;
descriptor.fs_descs.source.bLength = sizeof descriptor.fs_descs.source;
descriptor.fs_descs.source.bmAttributes = USB_ENDPOINT_XFER_BULK;
/* .wMaxPacketSize = autoconfiguration (kernel) */
descriptor.fs_descs.sink.bDescriptorType = USB_DT_ENDPOINT;
descriptor.fs_descs.sink.bEndpointAddress = 1 | USB_DIR_IN;
descriptor.fs_descs.sink.bLength = sizeof descriptor.fs_descs.source;
descriptor.fs_descs.sink.bmAttributes = USB_ENDPOINT_XFER_BULK;
/* .wMaxPacketSize = autoconfiguration (kernel) */
descriptor.hs_descs.source_sink_intf.bLength = sizeof descriptor.hs_descs.source_sink_intf;
descriptor.hs_descs.source_sink_intf.bDescriptorType = USB_DT_INTERFACE;
descriptor.hs_descs.source_sink_intf.bNumEndpoints = 2;
descriptor.hs_descs.source_sink_intf.bInterfaceClass = USB_CLASS_VENDOR_SPEC;
descriptor.hs_descs.source_sink_intf.iInterface = 1;
descriptor.hs_descs.source.bDescriptorType = USB_DT_ENDPOINT;
descriptor.hs_descs.source.bEndpointAddress = 1 | USB_DIR_OUT;
descriptor.hs_descs.source.bLength = sizeof descriptor.hs_descs.source;
descriptor.hs_descs.source.bmAttributes = USB_ENDPOINT_XFER_BULK;
/* .wMaxPacketSize = autoconfiguration (kernel) */
descriptor.hs_descs.sink.bDescriptorType = USB_DT_ENDPOINT;
descriptor.hs_descs.sink.bEndpointAddress = 1 | USB_DIR_IN;
descriptor.hs_descs.sink.bLength = sizeof descriptor.hs_descs.source;
descriptor.hs_descs.sink.bmAttributes = USB_ENDPOINT_XFER_BULK;
/* .wMaxPacketSize = autoconfiguration (kernel) */
return descriptor;
}

Gdb debugging c++, object printing

For example I can print this chunk of code with command:
print *hostx
and I get the result:
$22 = (Adaptation::Ecap::XactionRep) {<Adaptation::Initiate> = {<AsyncJob> = {_vptr.AsyncJob = 0x8beac8, stopReason = 0x0,
typeName = 0x662553 "Adaptation::Ecap::XactionRep", inCall = {p_ = 0xc8a440}, id = {static Prefix = 0x65800f "job", value = 50, static Last = 50}},
_vptr.Initiate = 0x8be858, theInitiator = {cbc = 0xc712a0, lock = 0xc71288}}, <libecap::host::Xaction> = {<libecap::Callable> = {
_vptr.Callable = 0x8be958}, <No data fields>}, <BodyConsumer> = {_vptr.BodyConsumer = 0x8bea18}, <BodyProducer> = {_vptr.BodyProducer = 0x8bea58},
theMaster = {<std::tr1::__shared_ptr<libecap::adapter::Xaction, (__gnu_cxx::_Lock_policy)2>> = {_M_ptr = 0xc93c00, _M_refcount = {
_M_pi = 0xc7d520}}, <No data fields>}, theService = {p_ = 0xc56b70}, theVirginRep = {<libecap::Message> = {_vptr.Message = 0x8befd0}, theMessage = {
header = 0xc8be10, body_pipe = {p_ = 0x0}}, theFirstLineRep = 0xca4880, theHeaderRep = 0xcac1f0, theBodyRep = 0x0}, theCauseRep = 0x0,
theAnswerRep = {<std::tr1::__shared_ptr<libecap::Message, (__gnu_cxx::_Lock_policy)2>> = {_M_ptr = 0x0, _M_refcount = {_M_pi = 0x0}}, <No data fields>},
makingVb = Adaptation::Ecap::XactionRep::opNever, proxyingAb = Adaptation::Ecap::XactionRep::opUndecided, adaptHistoryId = -1, vbProductionFinished = false,
abProductionFinished = false, abProductionAtEnd = false, static CBDATA_XactionRep = 22}
Question is how can I print these objects values inside hostx in gdb?
Using standard C/C++ syntax, e.g. print hostx->id

What Causes Boost Asio to Crash Like This?

My program appears to run just fine most of the time, but occasionally I get a segmentation fault.
boost version = 1.41.0
running on RHEL 4
compiled with GCC 3.4.6
Backtrace:
#0 0x08138546 in boost::asio::detail::posix_fd_set_adapter::is_set (this=0xb74ed020, descriptor=-1)
at /home/scottl/boost_1_41_0/boost/asio/detail/posix_fd_set_adapter.hpp:57
__result = -1 'ÿ'
#1 0x0813e1b0 in boost::asio::detail::reactor_op_queue::perform_operations_for_descriptors (this=0x97f3b6c, descriptors=#0xb74ed020, result=#0xb74ecec8)
at /home/scottl/boost_1_41_0/boost/asio/detail/reactor_op_queue.hpp:204
op_iter = {_M_node = 0xb4169aa0}
i = {_M_node = 0x97f3b74}
#2 0x081382ca in boost::asio::detail::select_reactor::run (this=0x97f3b08, block=true)
at /home/scottl/boost_1_41_0/boost/asio/detail/select_reactor.hpp:388
read_fds = {fd_set_ = {fds_bits = {16, 0 }}, max_descriptor_ = 65}
write_fds = {fd_set_ = {fds_bits = {0 }}, max_descriptor_ = -1}
retval = 1
lock = { = {}, mutex_ = #0x97f3b1c, locked_ = true}
except_fds = {fd_set_ = {fds_bits = {0 }}, max_descriptor_ = -1}
max_fd = 65
tv_buf = {tv_sec = 0, tv_usec = 710000}
tv = (timeval *) 0xb74ecf88
ec = {m_val = 0, m_cat = 0x81f2c24}
sb = { = {}, blocked_ = true, old_mask_ = {__val = {0, 0, 134590223,
3075395548, 3075395548, 3075395464, 134729792, 3075395360, 135890240, 3075395368, 134593920, 3075395544, 135890240,
3075395384, 134599542, 3020998404, 135890240, 3075395400, 134614095, 3075395544, 4, 3075395416, 134548135, 3021172996,
4294967295, 3075395432, 134692921, 3075395504, 0, 3075395448, 134548107, 3021172992}}}
#3 0x0812eb45 in boost::asio::detail::task_io_service >::do_one (this=0x97f3a70,
lock=#0xb74ed230, this_idle_thread=0xb74ed240, ec=#0xb74ed2c0)
at /home/scottl/boost_1_41_0/boost/asio/detail/task_io_service.hpp:260
more_handlers = false
c = {lock_ = #0xb74ed230, task_io_service_ = #0x97f3a70}
h = (boost::asio::detail::handler_queue::handler *) 0x97f3aa0
polling = false
task_has_run = true
#4 0x0812765f in boost::asio::detail::task_io_service >::run (this=0x97f3a70,
ec=#0xb74ed2c0) at /home/scottl/boost_1_41_0/boost/asio/detail/task_io_service.hpp:103
ctx = { = {}, owner_ = 0x97f3a70, next_ = 0x0}
this_idle_thread = {wakeup_event = { = {}, cond_ = {__c_lock = {
__status = 0, __spinlock = 22446}, __c_waiting = 0x2bd7,
__padding = "\000\000\000\000×+\000\000\000\000\000\000×+\000\000\000\000\000\000\204:\177\t\000\000\000", __align = 0},
signalled_ = true}, next = 0x0}
lock = { = {}, mutex_ = #0x97f3a84, locked_ = false}
n = 11420
#5 0x08125e99 in boost::asio::io_service::run (this=0x97ebbcc) at /home/scottl/boost_1_41_0/boost/asio/impl/io_service.ipp:58
ec = {m_val = 0, m_cat = 0x81f2c24}
s = 8
#6 0x08154424 in boost::_mfi::mf0::operator() (this=0x9800870, p=0x97ebbcc)
at /home/scottl/boost_1_41_0/boost/bind/mem_fn_template.hpp:49
No locals.
#7 0x08154331 in boost::_bi::list1 >::operator(), boost::_bi::list0> (this=0x9800878, f=#0x9800870, a=#0xb74ed337)
at /home/scottl/boost_1_41_0/boost/bind/bind.hpp:236
No locals.
#8 0x081541e5 in boost::_bi::bind_t, boost::_bi::list1 > >::operator() (this=0x9800870) at /home/scottl/boost_1_41_0/boost/bind/bind_template.hpp:20
a = {}
#9 0x08154075 in boost::detail::thread_data, boost::_bi::list1 > > >::run (this=0x98007a0)
at /home/scottl/boost_1_41_0/boost/thread/detail/thread.hpp:56
No locals.
#10 0x0816fefd in thread_proxy () at /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/locale_facets.tcc:2443
__ioinit = {static _S_refcount = , static _S_synced_with_stdio = }
---Type to continue, or q to quit---
typeinfo for common::RuntimeException = {}
typeinfo name for common::RuntimeException = "N6common16RuntimeExceptionE"
#11 0x00af23cc in start_thread () from /lib/tls/libpthread.so.0
No symbol table info available.
#12 0x00a5c96e in __init_misc () from /lib/tls/libc.so.6
No symbol table info available.
Without seeing the code in question, I can only guess, but I've had asio crash on several occasions due to the object whose method has been passed (via boost::bind) to asio has been deleted before asio calls the method.