[Users] [Bug 3069] Crash with the new libetpan callback logger

[noreply at thewildbeast.co.uk]

http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3069

--- Comment #9 from Michael Shell <list1 at michaelshell.org> ---
Created attachment 1360
  -->
http://www.thewildbeast.co.uk/claws-mail/bugzilla/attachment.cgi?id=1360&action=edit
Patch to fix nntp segmentation fault in libetpan v1.2/1.3

I recently ran into what I believe is the same problem under Claws Mail
3.9.3 with libetpan 1.3.pre2. Although in my case the seg fault happens
reliably and immediately upon trying to read a newsgroup and my gdb
backtrace is slightly different:


Thread 2 (Thread -1243321456 (LWP 2762)):
#0  0x000004ea in ?? ()
#1  0xb68fb232 in nntp_logger (s=0x8470cf0, log_type=0, 
    str=0xb6931fcb "<<<<<<< read <<<<<<\n", size=20, context=0x86a4b18)
    at newsnntp.c:2552
#2  0xb68be232 in low_logger (s=0x8470e30, log_type=0, 
    str=0xb6931fcb "<<<<<<< read <<<<<<\n", size=20, context=0x8470cf0)
    at mailstream.c:287



The difference in our backtraces may be due to different mail
configurations and/or libetpan versions. The fault in my system occurs
in the nntp_logger() of libetpan (not the function of the same name in
Claws Mail).


nntp_logger() is a simple function around line 2543 in
src/low-level/nntp/newsnntp.c of libetpan:



static inline void nntp_logger(mailstream * s, int log_type,
    const char * str, size_t size, void * context)
{
  newsnntp * session;

  session = context;
  if (session->nntp_logger == NULL)
    return;

  session->nntp_logger(session, log_type, str, size,
session->nntp_logger_context);
}



The problem seems to be that session->nntp_logger is pointing to
something invalid (and not NULL) which would explain why gbd is unable
to provide a name for it:


#0  0x000004ea in ?? ()


It appears that session->nntp_logger is not being set to NULL during
initialization. And indeed this is done in the other protocols
(e.g., smtp, imap, etc.).

For example, in src/low-level/smtp/mailsmtp.c there is a function
mailsmtp_new() starting around line 107 that has at around line 141:



        session->smtp_timeout = 0;

  session->smtp_logger = NULL;
  session->smtp_logger_context = NULL;

  return session;



However, look at the corresponding code for the function newsnntp_new()
starting around line 88 in src/low-level/nntp/newsnntp.c:



newsnntp * newsnntp_new(size_t progr_rate, progress_function * progr_fun)
{
  newsnntp * f;

  f = malloc(sizeof(* f));
  if (f == NULL)
    goto err;

  f->nntp_stream = NULL;
  f->nntp_readonly = FALSE;

  f->nntp_progr_rate = progr_rate;
  f->nntp_progr_fun = progr_fun;

  f->nntp_stream_buffer = mmap_string_new("");
  if (f->nntp_stream_buffer == NULL)
    goto free_f;

  f->nntp_response_buffer = mmap_string_new("");
  if (f->nntp_response_buffer == NULL)
    goto free_stream_buffer;

        f->nntp_timeout = 0;

  return f;

 free_stream_buffer:
    mmap_string_free(f->nntp_stream_buffer);
 free_f:
    free(f);
 err:
    return NULL;




If I am understanding things correctly, there is supposed be lines to
initialize the pointers for the nntp_logger to NULL just after the
setting of the nntp_timeout line (around line 110) in newsnntp_new():



         f->nntp_timeout = 0;

  f->nntp_logger = NULL;
  f->nntp_logger_context = NULL;

  return f;



In this way, libetpan's nntp_logger() will not attempt to transfer
execution to the pointer until after the application actually sets up
a logger with libetpan (if ever). (Claws Mail does its own nntp logging
because libetpan did not even provide a logging framework for nntp until
version 1.2.)


The attached patch file, fix_libetpan_nntp_logger_seg_fault.patch, that
I wrote for libetpan 1.3.pre2 adds these two null setting lines. It fixes
the problem on my system.


Please do let us know if it works (or not) for anyone else so we can confirm
it. If indeed it is a libetpan problem, upstream should be notified and this
bug report for Claws Mail can be closed.



  Cheers,

  Mike Shell

-- 
You are receiving this mail because:
You are the assignee for the bug.