On Sun, Mar 9, 2008 at 2:07 AM, Diego Liziero diegoliz@gmail.com wrote:
[..]
180 (124 direct, 56 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 5 [..] by 0x80B59CB: mail_transaction_log_file_alloc (mail-transaction-log-file.c:51) by 0x80B3A86: mail_transaction_log_find_file (mail-transaction-log.c:385)
I think that it's this last line causing the error.
---- mail-transaction-log.c 343 int mail_transaction_log_find_file(struct mail_transaction_log *log, 344 uint32_t file_seq, bool nfs_flush, 345 struct mail_transaction_log_file **file_r) 346 { 347 struct mail_transaction_log_file *file; 348 const char *path; 349 int ret; [..] 382 /* see if we have it in log.2 file */ 383 path = t_strconcat(log->index->filepath, 384 MAIL_TRANSACTION_LOG_SUFFIX".2", NULL); 385 file = mail_transaction_log_file_alloc(log, path);
Here a new mail_transaction_log_file is allocated before getting lost. Maybe I'm wrong, but, isn't here a path where mail_transaction_log_file_free(&file); should be called before returning without losing the memory pointed by file?
386 if ((ret = mail_transaction_log_file_open(file, TRUE)) <= 0) 387 return ret; 388 389 /* but is it what we expected? */ 390 if (file->hdr.file_seq != file_seq) 391 return 0; 392 393 *file_r = file; 394 return 1; 395 }
Regards, Diego.