[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-devel] SIGSEGV @ (abort_flag)

From: Nathanael Hoyle
Subject: Re: [Pan-devel] SIGSEGV @ (abort_flag)
Date: Sat, 29 Aug 2009 15:31:16 -0400

I am not specifically familiar with this code, but since no one else has replied... I don't believe that this is duplicate.

Firstly, the if statement block that you commented out occurs within the else clause of the if structure which first checks for _abort_flag. This means that logically, _abort_flag must *not* be set in order to ever enter the else block, and therefore, if it were a duplicate/redundant check, then _abort_flag would never be set when checked the second time (where you commented it out). The fact that commenting it out caused a change in behavior for you proves that it is possible for _abort_flag to not be set in the first test, but to be set in the second. Presumably, this is because either/both of do_read() or do_write() may set _abort_flag (in the else block, above your "duplicate" if). I expect your actual problem lies elsewhere (perhaps within the on_socket_abort() call).


On Aug 21, 2009, at 4:10 PM, Heinrich Müller wrote:

OS: 64 bit ubuntu jaunty 9.04, latest version from SVN.

code snippet //

/if (_abort_flag)
  _listener->on_socket_abort (this);
else if (!(cond & (G_IO_IN | G_IO_OUT)))
  _listener->on_socket_error (this);
else // G_IO_IN or G_IO_OUT
  const DoResult result = (cond & G_IO_IN) ? do_read () : do_write ();
  /*  if (_abort_flag)        _listener->on_socket_abort (this);
  else*/ if (result == IO_ERR)   _listener->on_socket_error (this);
  else if (result == IO_READ)  set_watch_mode (READ_NOW);
  else if (result == IO_WRITE) set_watch_mode (WRITE_NOW);


isn't the second appearance of abort_flag a dupe? it was already checked before by the first "if" branch... i commented that and got no errors so far (opposed to random segfaults before) :D

Pan-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]