pan-devel
[Top][All Lists]
Advanced

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

Re: [Pan-devel] SIGSEGV @ socket-impl-gio.cc:502 (abort_flag)


From: Heinrich Mueller
Subject: Re: [Pan-devel] SIGSEGV @ socket-impl-gio.cc:502 (abort_flag)
Date: Sun, 30 Aug 2009 09:06:47 +0200
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

Nathanael Hoyle schrieb:

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).

-Nathanael

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
address@hidden
http://lists.nongnu.org/mailman/listinfo/pan-devel

that's what i believe, too. the else branch wouldn't have the _abort_flag set, but the code has a check there.
odd.
gdb says that the call for _listener->on_socket_abort (this) causes a SIGSEGV on exactly this line (inside the else branch).

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f61faa28790 (LWP 12446)]
0x000000000052431a in pan::GIOChannelSocket::gio_func (this=0x3281b60,
  channel=0x8e98340, cond=G_IO_IN) at socket-impl-gio.cc:502
502             if (_abort_flag)        _listener->on_socket_abort (this);




reply via email to

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