[Dovecot] Dovecot 1.1.1 killed with SIGABRT
Hi folks,
with Dovecot 1.1.1, I've had two "crashes" (SIGABRT) recently. Dovecot 1.1.1 has been compiled from source and is running on Fedora 8 Linux 32 Bit (all patches) with custom OpenSSL 0.9.8h.
[ output of "dovecot -n" ] # 1.1.1: /usr/local/dovecot/etc/dovecot.conf ssl_cert_file: /usr/local/dovecot/etc/dovecot.crt ssl_key_file: /usr/local/dovecot/etc/dovecot.key login_dir: /usr/local/dovecot/var/run/dovecot/login login_executable: /usr/local/dovecot/libexec/dovecot/imap-login mail_location: mbox:~/Mail:INBOX=/var/spool/mail/%u auth default: mechanisms: plain login digest-md5 cram-md5 passdb: driver: passwd-file args: /usr/local/dovecot/etc/dovecot.passwd userdb: driver: passwd-file args: /usr/local/dovecot/etc/dovecot.passwd
First, the "small" problem with Pine 4.64:
Jul 20 03:17:04 linux dovecot: imap-login: Login: user=<user1>, method=CRAM-MD5, rip=138.201.2.8, lip=138.201.2.2, TLS Jul 20 03:17:53 linux dovecot: IMAP(user1): UIDVALIDITY changed (1215137127 -> 1216072777) in mbox file /home/user1/Mail/Trash Jul 20 03:17:53 linux dovecot: Panic: IMAP(user1): file mail-index-transaction.c: line 548 (mail_index_transaction_get_next_uid): assertion failed: (recs[count-1].uid >= next_uid) Jul 20 03:17:53 linux dovecot: IMAP(user1): Raw backtrace: imap [0x80cf2f0] -> imap [0x80cf34a] -> imap [0x80cec5c] -> imap [0x80ad621] -> imap [0x80ae56b] -> imap(mail_cache_get_first_new_seq+0x12) [0x80a1d82] -> imap(mail_cache_field_want_add+0x8d) [0x80a555d] -> imap(index_mail_parse_header_init+0x1cc) [0x80964ac] -> imap(index_mail_cache_parse_init+0x4e) [0x809696e] -> imap(mbox_save_init+0x457) [0x807d4a7] -> imap(mailbox_save_init+0x51) [0x809fd71] -> imap(mail_storage_copy+0xc1) [0x809df31] -> imap(cmd_copy+0x1d2) [0x805b1f2] -> imap(cmd_uid+0x59) [0x805f489] -> imap [0x805fe2c] -> imap [0x805fed5] -> imap [0x8060695] -> imap(client_input+0x5e) [0x80608ae] -> imap(io_loop_handler_run+0x100) [0x80d6c30] -> imap(io_loop_run+0x28) [0x80d5dc8] -> imap(main+0x4a1) [0x80683d1] -> /lib/libc.so.6(__libc_start_main+0xe0) [0x149390] -> imap [0x805a211] Jul 20 03:17:53 linux dovecot: child 19853 (imap) killed with signal 6
The user didn't configure his Pine properly. He used IMAP to access his INBOX, but he forgot to configure this for all other folders as well. Now, Pine modified /home/user1/Mail/Trash directly, and when Dovecot stumbled upon this file it killed itself with signal 6.
The problem is not reproducible. After this single failure, Dovecot doesn't seem to have any problems with the folder.
However, instead of this panic operation, Dovecot maybe could issue a warning or error response to the client so that the user (hopefully) gets a clue about what's going wrong.
Second, the "big" problem with Thunderbird 2.0.0.14:
Jul 12 01:04:06 linux dovecot: imap-login: Login: user=<user2>, method=CRAM-MD5, rip=138.201.2.4, lip=138.201.2.2, TLS Jul 12 01:04:45 linux dovecot: Panic: IMAP(user2): file index-sync.c: line 39 (index_mailbox_set_recent_uid): assertion failed: (seq_range_exists(&ibox->recent_flags, uid)) Jul 12 01:04:45 linux dovecot: IMAP(user2): Raw backtrace: imap [0x80cf2f0] -> imap [0x80cf34a] -> imap [0x80cec5c] -> imap [0x809ccba] -> imap [0x8080d10] -> imap(mbox_sync+0x522) [0x80817d2] -> imap [0x807a334] -> imap(index_transaction_commit+0x4e) [0x809d99e] -> imap(cmd_copy+0x35f) [0x805b37f] -> imap(cmd_uid+0x59) [0x805f489] -> imap [0x805fe2c] -> imap [0x805fed5] -> imap [0x8060695] -> imap(client_input+0x5e) [0x80608ae] -> imap(io_loop_handler_run+0x100) [0x80d6c30] -> imap(io_loop_run+0x28) [0x80d5dc8] -> imap(main+0x4a1) [0x80683d1] -> /lib/libc.so.6(__libc_start_main+0xe0) [0x149390] -> imap [0x805a211] Jul 12 01:04:45 linux dovecot: child 25672 (imap) killed with signal 6 [happens over and over in an endless loop until Thunderbird is killed]
This has been a nasty one. Different user, different mail client.
INBOX with 350 messages in total, 3 of them new. Started Thunderbird, index page is displayed fine, then clicked on one of the 3 new messages to read it. For no apparent reason, Dovecot dies with signal 6. Thunderbird reconnected automatically, and then Dovecot dies again. Nice endless loop ...
Stopping and restarting the complete Dovecot subsystem with the help of the init.d script didn't help. Finally the crashes stopped after removing the cache files in /home/fubar/Mail/.imap/INBOX.
It's obvious that the cache files got corrupted somehow. There was plenty of disk space free. And the cache files have been freshly created from scratch with Dovecot 1.1.0. Other folders were not affected. Except Dovecot, nobody ever touches these cache files.
Well, the good news is, it stopped crashing after removing the cache files. The bad news is, without the cache files (which I removed) the problem cannot be reproduced.
So, there's nothing more to offer than these two backtraces. Both crashes are not related to each other and happened to different users with different clients.
Maybe the backtraces and my descriptions help to find what's going wrong or how to make Dovecot behave more robustly. If there's any additional information needed, please let me know. Sorry that I didn't save the corrupted cache files.
Greetings, AndreasOn Mon, 2008-07-21 at 01:24 +0200, Andreas M. Kirchwitz wrote:
First, the "small" problem with Pine 4.64:
Jul 20 03:17:04 linux dovecot: imap-login: Login: user=<user1>, method=CRAM-MD5, rip=138.201.2.8, lip=138.201.2.2, TLS Jul 20 03:17:53 linux dovecot: IMAP(user1): UIDVALIDITY changed (1215137127 -> 1216072777) in mbox file /home/user1/Mail/Trash Jul 20 03:17:53 linux dovecot: Panic: IMAP(user1): file mail-index-transaction.c: line 548 (mail_index_transaction_get_next_uid): assertion failed: (recs[count-1].uid >= next_uid)
Fixed: http://hg.dovecot.org/dovecot-1.1/rev/ea00b1553ef1
However, instead of this panic operation, Dovecot maybe could issue a warning or error response to the client so that the user (hopefully) gets a clue about what's going wrong.
This should be transparent to the client. After the above fix it still logs the warning and also a couple of more errors that I should probably look into why they're happening.
Jul 12 01:04:45 linux dovecot: Panic: IMAP(user2): file index-sync.c: line 39 (index_mailbox_set_recent_uid): assertion failed: (seq_range_exists(&ibox->recent_flags, uid))
This seems to be happening with some mbox users. I guess I should try to look at it again, but I haven't been able to reproduce it myself so far. If you've any idea how to somewhat easily reproduce it, I'd like to know.
If it still happens randomly, you could just comment out that line. That'll cause recent flags to be somewhat wrong sometimes, but Thunderbird doesn't care about them.
INBOX with 350 messages in total, 3 of them new. Started Thunderbird, index page is displayed fine, then clicked on one of the 3 new messages to read it. For no apparent reason, Dovecot dies with signal 6. Thunderbird reconnected automatically, and then Dovecot dies again. Nice endless loop ...
If this still happens, I'd really like to have:
- Output of "find ~/Maildir" (i.e. a list of all files in maildir)
- dovecot-uidlist
- dovecot.index and dovecot.index.log
None of those should contain anything sensitive about the mailbox contents.
Stopping and restarting the complete Dovecot subsystem with the help of the init.d script didn't help. Finally the crashes stopped after removing the cache files in /home/fubar/Mail/.imap/INBOX.
It's obvious that the cache files got corrupted somehow. There was plenty of disk space free. And the cache files have been freshly created from scratch with Dovecot 1.1.0. Other folders were not affected. Except Dovecot, nobody ever touches these cache files.
By "cache files" do you mean dovecot.index*? The dovecot.index.cache file should have nothing to do with this problem.
Well, the good news is, it stopped crashing after removing the cache files. The bad news is, without the cache files (which I removed) the problem cannot be reproduced.
Yes, it would have been nice to have them.. :)
Was this a completely new Dovecot installation, so Dovecot v1.0 was never run?
On Mon, 2008-07-21 at 03:28 +0300, Timo Sirainen wrote:
INBOX with 350 messages in total, 3 of them new. Started Thunderbird, index page is displayed fine, then clicked on one of the 3 new messages to read it. For no apparent reason, Dovecot dies with signal 6. Thunderbird reconnected automatically, and then Dovecot dies again. Nice endless loop ...
If this still happens, I'd really like to have:
- Output of "find ~/Maildir" (i.e. a list of all files in maildir)
- dovecot-uidlist
- dovecot.index and dovecot.index.log
None of those should contain anything sensitive about the mailbox contents.
Oh, right, this is a mbox problem, not maildir problem. :) So a small change to the want-list:
- mbox file put through http://dovecot.org/tools/mbox-anonymize.pl
- dovecot.index and dovecot.index.log
Timo Sirainen wrote:
Great, thanks!
Jul 12 01:04:45 linux dovecot: Panic: IMAP(user2): file index-sync.c: line 39 (index_mailbox_set_recent_uid): assertion failed: (seq_range_exists(&ibox->recent_flags, uid))
Stopping and restarting the complete Dovecot subsystem with the help of the init.d script didn't help. Finally the crashes stopped after removing the cache files in /home/user2/Mail/.imap/INBOX.
By "cache files" do you mean dovecot.index*? The dovecot.index.cache file should have nothing to do with this problem.
Hmm, yes, I think so. But now that you ask, hmm, there might be a slight chance that I also stripped the IMAP-related header keywords (X-IMAP*, X-UID*) from /var/spool/mail/user2. But before you asked I was pretty sure I just removed the directory ~user2/Mail/.imap/INBOX (containing dovecot.index, dovecot.index.cache and dovecot.index.log).
The reason I'm not 100% sure is that, after things were working again, I stopped Dovecot, removed all caches (Dovecot + Thunderbird) and *then* stripped the IMAP-related header keywords; just to make sure that all applications don't use any "bad data" that were left over by the crash. Well, it happened a week ago... I'm really unsure now, sorry.
Would that make more sense if I had not just removed the cache files but also stripped the IMAP-related header keywords from the INBOX file?
Was this a completely new Dovecot installation, so Dovecot v1.0 was never run?
When I replaced Dovecot 1.0 with the new Dovecot 1.1, I removed the cache files (rm -rf /home/*/Mail/.imap) and also stripped the IMAP-related header keywords from all mbox files (X-IMAP*, X-UID*). Don't worry, I don't do this for every update, but I did a lot of things with my old Dovecot 1.0 installation, and I had this feeling that now it's a good time for some clean-up. ;-)
Btw, I've had this problem only once. Never before, never after that. So whatever it is, it happens very rarely. If it happens again, I promise, I'll better keep track of my actions and all files.
Greetings ... AndreasOn Mon, 2008-07-21 at 18:08 +0200, Andreas M. Kirchwitz wrote:
Jul 12 01:04:45 linux dovecot: Panic: IMAP(user2): file index-sync.c: line 39 (index_mailbox_set_recent_uid): assertion failed: (seq_range_exists(&ibox->recent_flags, uid))
I think I finally managed to fix this: http://hg.dovecot.org/dovecot-1.1/rev/48bbaf0c3e4d
I was able to reproduce it with imaptest by running two of them:
imaptest copybox=Trash clients=5 msgs=10000 delete=10 expunge=10 copy=100 logout=1 imaptest box=Trash clients=2 append=0 msgs=10000 expunge=10 delete=10 logout=1 rawlog
The problem was that Dovecot marked messages \Recent only when it read them from the mbox file. But when messages were saved by Dovecot itself, they were already in index files so there wasn't any need to read them. Then in some situations Dovecot could read the messages in reverse order and try to set the \Recent flags in that order.
On Mon, Jul 21, 2008 at 8:13 PM, Timo Sirainen tss@iki.fi wrote:
On Mon, 2008-07-21 at 18:08 +0200, Andreas M. Kirchwitz wrote:
Jul 12 01:04:45 linux dovecot: Panic: IMAP(user2): file index-sync.c: line 39 (index_mailbox_set_recent_uid): assertion failed: (seq_range_exists(&ibox->recent_flags, uid))
I think I finally managed to fix this: http://hg.dovecot.org/dovecot-1.1/rev/48bbaf0c3e4d
Unfortunately just got it again with dovecot 1.1.2 seq_range_exists(&ibox->recent_flags, uid) ibox->recent_flags=164556344 uid=8
On Fri, Aug 1, 2008 at 12:00 PM, Diego Liziero diegoliz@gmail.com wrote:
On Mon, Jul 21, 2008 at 8:13 PM, Timo Sirainen tss@iki.fi wrote:
On Mon, 2008-07-21 at 18:08 +0200, Andreas M. Kirchwitz wrote:
Jul 12 01:04:45 linux dovecot: Panic: IMAP(user2): file index-sync.c: line 39 (index_mailbox_set_recent_uid): assertion failed: (seq_range_exists(&ibox->recent_flags, uid))
I think I finally managed to fix this: http://hg.dovecot.org/dovecot-1.1/rev/48bbaf0c3e4d
Unfortunately just got it again with dovecot 1.1.2 seq_range_exists(&ibox->recent_flags, uid)
Got it again, I've exec and core file, if you need them.
BTW, I'm getting this assertion failure definetly less frequently than before.
Could it be just a leftover from the previous unpatched version?
Regards, Diego.
Panic: IMAP(user): file index-sync.c: line 42 (index_mailbox_set_recent_uid): assertion failed: (seq_range_exists(&ibox->recent_flags, uid)) Error: IMAP(user): Raw backtrace: /usr/libexec/dovecot/imap [0x80f609c] -> /usr/libexec/dovecot/imap [0x80f693f] -> /usr/libexec/dovecot/imap(i_fatal+0) [0x80f61f8] -> /usr/libexec/dovecot/imap(index_mailbox_set_recent_uid+0xbc) [0x80b201f] -> /usr/libexec/dovecot/imap(index_mailbox_set_recent_seq+0x33) [0x80b2095] -> /usr/libexec/dovecot/imap [0x808f02b] -> /usr/libexec/dovecot/imap [0x808f64d] -> /usr/libexec/dovecot/imap [0x808ffb7] -> /usr/libexec/dovecot/imap(mbox_sync+0x2b) [0x8090243] -> /usr/libexec/dovecot/imap [0x80851a1] -> /usr/libexec/dovecot/imap(mail_index_transaction_commit+0x59) [0x80c6df2] -> /usr/libexec/dovecot/imap(index_transaction_commit+0x65) [0x80b3901] -> /usr/libexec/dovecot/imap(mailbox_transaction_commit_get_uids+0x50) [0x80b6bce] -> /usr/libexec/dovecot/imap [0x805a994] -> /usr/libexec/dovecot/imap [0x805a3a0] -> /usr/libexec/dovecot/imap(io_loop_handler_run+0x17d) [0x81006e8] -> /usr/libexec/dovecot/imap(io_loop_run+0x35) [0x80ff996] -> /usr/libexec/dovecot/imap(main+0xe4) [0x806de3d] -> /lib/li Error: IMAP(user): bc.so.6(__libc_start_main+0xdc) [0x42bdec] -> /usr/libexec/dovecot/imap [0x805a1a1] Error: child 14026 (imap) killed with signal 6
(gdb) bt full No symbol table info available. #1 0x0043ed20 in raise () from /lib/libc.so.6 No symbol table info available. #2 0x00440631 in abort () from /lib/libc.so.6 No symbol table info available. #3 0x080f60be in default_fatal_finish (type=LOG_TYPE_PANIC, status=0) at failures.c:149 backtrace = 0x9f34738 "/usr/libexec/dovecot/imap [0x80f609c] -> /usr/libexec/dovecot/imap [0x80f693f] -> /usr/libexec/dovecot/imap(i_fatal+0) [0x80f61f8] -> /usr/libexec/dovecot/imap(index_mailbox_set_recent_uid+0xbc) [0x80"... #4 0x080f693f in i_internal_fatal_handler (type=LOG_TYPE_PANIC, status=0, fmt=0x8119ea0 "file %s: line %d (%s): assertion failed: (%s)", args=0xbfe8da34 "\223\236\021\b*") at failures.c:423 No locals. #5 0x080f61f8 in i_panic (format=0x8119ea0 "file %s: line %d (%s): assertion failed: (%s)") at failures.c:190 args = 0xbfe8da34 "\223\236\021\b*" #6 0x080b201f in index_mailbox_set_recent_uid (ibox=0x9f46e48, uid=14) at index-sync.c:42 __PRETTY_FUNCTION__ = "index_mailbox_set_recent_uid" #7 0x080b2095 in index_mailbox_set_recent_seq (ibox=0x9f46e48, view=0x9f50c10, seq1=2, seq2=7) at index-sync.c:59 uid = 14 #8 0x0808f02b in mbox_sync_update_index_header (sync_ctx=0xbfe8dc04) at mbox-sync.c:1424 view = (struct mail_index_view *) 0x9f50c10 st = (const struct stat *) 0x9f580c0 first_recent_uid = 0 seq = 2 seq2 = 7 __PRETTY_FUNCTION__ = "mbox_sync_update_index_header" #9 0x0808f64d in mbox_sync_do (sync_ctx=0xbfe8dc04, flags=18) at mbox-sync.c:1560 mail_ctx = {sync_ctx = 0xbfe8dc04, mail = {uid = 19, idx_seq = 7, keywords = {arr = {buffer = 0x0, element_size = 0}, v = 0x0, v_modifiable = 0x0}, flags = 40 '(', uid_broken = 0, expunged = 0, pseudo = 0, from_offset = 7366, body_size = 414, offset = 8025, space = 70}, seq = 7, hdr_offset = 7433, body_offset = 8117, header_first_change = 4294967295, header_last_change = 0, header = 0x9f57c80, hdr_md5_sum = "){\023??????\\??????y\226???Z\221?????????", content_length = 414, hdr_pos = {578, 4294967295, 592, 4294967295, 567}, parsed_uid = 19, last_uid_updated_value = 0, last_uid_value_start_pos = 0, have_eoh = 1, need_rewrite = 0, seen_imapbase = 0, updated = 0, recent = 1, dirty = 0, imapbase_rewrite = 0, imapbase_updated = 0} st = (const struct stat *) 0x9f580c0 i = 0 ret = 1 partial = 1 #10 0x0808ffb7 in mbox_sync_int (mbox=0x9f46e48, flags=18) at mbox-sync.c:1803 index_sync_ctx = (struct mail_index_sync_ctx *) 0x9f48700 sync_view = (struct mail_index_view *) 0x9f48780 trans = (struct mail_index_transaction *) 0x9f48e48 sync_ctx = {mbox = 0x9f46e48, flags = 18, input = 0x9f4c9f8, file_input = 0x9f580a0, write_fd = 10, orig_mtime = 1218018624, orig_atime = 1218017251, orig_size = 8532, last_stat = {st_dev = 37637, __pad1 = 0, __st_ino = 8896514, st_mode = 33152, st_nlink = 1, st_uid = 1470, st_gid = 508, st_rdev = 0, __pad2 = 0, st_size = 8532, st_blksize = 4096, st_blocks = 32, st_atim = { tv_sec = 1218018624, tv_nsec = 0}, st_mtim = {tv_sec = 1218018624, tv_nsec = 0}, st_ctim = {tv_sec = 1218018624, tv_nsec = 0}, st_ino = 8896514}, index_sync_ctx = 0x9f48700, sync_view = 0x9f48780, t = 0x9f48e48, reset_hdr = {major_version = 0 '\0', minor_version = 0 '\0', base_header_size = 0, header_size = 0, record_size = 0, compat_flags = 0 '\0', unused = "\000\000", indexid = 0, flags = 0, uid_validity = 0, next_uid = 0, messages_count = 0, unused_old_recent_messages_count = 0, seen_messages_count = 0, deleted_messages_count = 0, first_recent_uid = 0, first_unseen_uid_lowwater = 0, first_deleted_uid_lowwater = 0, log_file_seq = 0, log_file_tail_offset = 0, log_file_head_offset = 0, sync_size = 0, sync_stamp = 0, day_stamp = 0, day_first_uid = {0, 0, 0, 0, 0, 0, 0, 0}}, hdr = 0x9f57cf0, header = 0x9f57c80, from_line = 0x9f57c60, base_uid_validity = 1141738008, base_uid_last = 13, base_uid_last_offset = 280, mails = {arr = {buffer = 0x9f57dd8, element_size = 52}, v = 0x9f57dd8, v_modifiable = 0x9f57dd8}, sync_changes = 0x9f57df8, mail_keyword_pool = 0x9f4be18, saved_keywords_pool = 0x9f58280, prev_msg_uid = 19, next_uid = 20, idx_next_uid = 20, seq = 7, idx_seq = 8, need_space_seq = 0, last_nonrecent_uid = 13, expunged_space = 0, space_diff = 0, dest_first_mail = 0, first_mail_crlf_expunged = 0, delay_writes = 0, renumber_uids = 0, moved_offsets = 0, ext_modified = 0, index_reset = 0, errors = 0} sync_flags = MAIL_INDEX_SYNC_FLAG_FLUSH_DIRTY lock_id = 3 ret = 1 changed = 1 delay_writes = false __PRETTY_FUNCTION__ = "mbox_sync_int" #11 0x08090243 in mbox_sync (mbox=0x9f46e48, flags=18) at mbox-sync.c:1870 ret = 0 #12 0x080851a1 in mbox_transaction_commit (t=0x9f48900, log_file_seq_r=0xbfe8dedc, log_file_offset_r=0xbfe8ded0) at mbox-transaction.c:45 mt = (struct mbox_transaction_context *) 0x0 mbox = (struct mbox_mailbox *) 0x9f46e48 lock_id = 3 mails_saved = true ret = 0 #13 0x080c6df2 in mail_index_transaction_commit (_t=0xbfe8dee0, log_file_seq_r=0xbfe8dedc, log_file_offset_r=0xbfe8ded0) at mail-index-transaction.c:631 t = (struct mail_index_transaction *) 0x9f48900 #14 0x080b3901 in index_transaction_commit (_t=0x9f48ba0, uid_validity_r=0xbfe8df5c, first_saved_uid_r=0xbfe8df58, last_saved_uid_r=0xbfe8df54) at index-transaction.c:105 t = (struct index_transaction_context *) 0x9f48ba0 itrans = (struct mail_index_transaction *) 0x0 seq = 2 offset = 964 #15 0x080b6bce in mailbox_transaction_commit_get_uids (_t=0x9f39690, uid_validity_r=0xbfe8df5c, first_saved_uid_r=0xbfe8df58, last_saved_uid_r=0xbfe8df54) at mail-storage.c:682 t = (struct mailbox_transaction_context *) 0x9f48ba0 #16 0x0805a994 in cmd_append_continue_parsing (cmd=0x9f39600) at cmd-append.c:252 uid2 = 19 msg = 0x1
sync_flags = 135289584 imap_flags = 166958264 uid_validity = 1141738008 uid1 = 19 client = (struct client *) 0x9f39368 ctx = (struct cmd_append_context *) 0x9f39680 args = (const struct imap_arg *) 0x9f492a0 flags_list = (const struct imap_arg *) 0x0 flags = MAIL_ANSWERED keywords_list = (const char * const *) 0x9f393d8 keywords = (struct mail_keywords *) 0xbc2 internal_date_str = 0xbfe8df88 "\001" internal_date = 0 ret = 1 timezone_offset = 166951376 nonsync = 191 __PRETTY_FUNCTION__ = "cmd_append_continue_parsing" #17 0x0805a3a0 in client_input_append (cmd=0x9f39600) at cmd-append.c:79 ctx = (struct cmd_append_context *) 0x9f39680 client = (struct client *) 0x9f39368 output = (struct ostream *) 0x9f394ec finished = false __PRETTY_FUNCTION__ = "client_input_append" #18 0x081006e8 in io_loop_handler_run (ioloop=0x9f379b0) at ioloop-epoll.c:201 ctx = (struct ioloop_handler_context *) 0x9f37aa8 events = (struct epoll_event *) 0x9f37ae8 event = (const struct epoll_event *) 0x9f37ae8 list = (struct io_list *) 0x9f39568 io = (struct io_file *) 0x9f39548 tv = {tv_sec = 1799, tv_usec = 990444} events_count = 3 t_id = 2 msecs = 1799991 ret = 1 i = 0 j = 0 call = true #19 0x080ff996 in io_loop_run (ioloop=0x9f379b0) at ioloop.c:308 No locals. #20 0x0806de3d in main (argc=1, argv=0xbfe8e104, envp=0xbfe8e10c) at main.c:293 No locals.
participants (3)
-
Andreas M. Kirchwitz
-
Diego Liziero
-
Timo Sirainen