SIGPIPE and crash linux 0.5.5-svn

Technical RetroShare discussions Forum

SIGPIPE and crash linux 0.5.5-svn

Postby nake » Wed Jan 14, 2015 8:11 pm

Hello again.

I'm having random crashes after a few hours (without touching anything at all, the program is in the taskbar) under linux (debian testing x86_64) using the latest svn version for branch 0.5.5 with the small patch I talked about in another thread.

GDB says it's a SIGPIPE error in ssl.
Code: Select all
[...]
ftController: Adding source Anonymous F2F tunnel <edited_out> to current download hash=<edited_out>ftController: Adding source Anonymous F2F tunnel <edited_out> to current download hash=<edited_out>Asserting that at least 3 are dedicated to user transfers.
  collected 0 transfers to move.
Asserting that at least 3 are dedicated to user transfers.
  collected 0 transfers to move.
Asserting that at least 3 are dedicated to user transfers.
  collected 0 transfers to move.

Program received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x7fffc2ffd700 (LWP 2160)]
0x00007ffff4459a7d in write () at ../sysdeps/unix/syscall-template.S:81

(gdb) bt
#0  0x00007ffff4459a7d in write () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff6df67d5 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#2  0x00007ffff6df47ec in BIO_write () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#3  0x00007ffff798e702 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
#4  0x00007ffff7990313 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
#5  0x00007ffff798c732 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
#6  0x0000000000c384af in pqissl::reset (this=0x7fffb00893d0) at pqi/pqissl.cc:220
#7  0x0000000000c3c6ad in pqissl::readdata (this=0x7fffb00893d0, data=0x7fffb0089680, len=8) at pqi/pqissl.cc:1628
#8  0x0000000000ba38e3 in pqistreamer::handleincoming (this=0x7fffb0089540) at pqi/pqistreamer.cc:480
#9  0x0000000000ba3240 in pqistreamer::tick (this=0x7fffb0089540) at pqi/pqistreamer.cc:192
#10 0x0000000000c341d7 in pqiperson::tick (this=0x7fffb00892d0) at pqi/pqiperson.cc:160
#11 0x0000000000b93d4e in pqihandler::tick (this=0x19636d0) at pqi/pqihandler.cc:75
#12 0x0000000000b9bb62 in pqipersongrp::tick (this=0x19636d0) at pqi/pqipersongrp.cc:140
#13 0x0000000000b55bf2 in ftServer::tick (this=0x1829540) at ft/ftserver.cc:1273
#14 0x0000000000ba9d61 in RsServer::run (this=0x14b04f0) at rsserver/p3face-server.cc:172
#15 0x0000000000b3dbd1 in rsthread_init (p=0x14b04f8) at util/rsthreads.cc:62
#16 0x00007ffff44530a4 in start_thread (arg=0x7fffc2ffd700) at pthread_create.c:309
#17 0x00007ffff3965ccd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111


The snippet that fails is this (in pqi/pqissl.cc):
Code: Select all
int    pqissl::reset()
{
   std::string outLog;

   /* a reset shouldn't cause us to stop listening
    * only reasons for stoplistening() are;
    *
    * (1) destruction.
    * (2) connection.
    * (3) WillListen state change
    *
    */

   outLog += "pqissl::reset():" + PeerId();
   rs_sprintf_append(outLog, " (A: %d", (int) active);
   rs_sprintf_append(outLog, " FD: %d", sockfd);
   rs_sprintf_append(outLog, " W: %d",  waiting);
   rs_sprintf_append(outLog, " SSL: %p) ", ssl_connection);
#ifdef PQISSL_LOG_DEBUG
   outLog += "\n";
#endif

   bool neededReset = false;

   if (ssl_connection != NULL)
   {
      //outLog << "pqissl::reset() Shutting down SSL Connection";
      //outLog << std::endl;
      SSL_shutdown(ssl_connection); // <<<<<<<<<<<<<< HERE CRASHES
      SSL_free (ssl_connection);

      neededReset = true;   
   }


I'm not sure what triggers this but since I fixed the other problem (the one about a failed fseek I talked about in my other thread) this one appears always. I don't know if it's related with my patch for the other fix.

By the way, I post here my bug reports and patches because I don't have access to the internal RS forums (I use RS with my friends only), but if someone with access want's to add me as friend I'd gladly send the bug reports there instead. Just send me a PM or something.

In the openssl mail list they talked about this problem back in the 2006, see http://comments.gmane.org/gmane.comp.encryption.openssl.user/20571.
They say that this problem happens when the connection is closed abruptly and the server calls SSL_shutdown, I'm gonna see if I can patch this and tell you what I did to fix it, but I'm not that sure if what I'm doing is ok or whatever. I sadly don't have the time to read the source code of RS (yet).

Thanks in advance and happy hacking!


EDIT:
Playing around I found this in the log files:
Code: Select all
Starting program: /home/nake/bin/retroshare-svn-0.5.5/retroshare-gui/src/RetroShare
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
RetroShare:: Successfully installed the SIGPIPE Block


And a log in the svn saying that SIGPIPE is controlled to avoid exactly the problem that I'm having. Might this be a problem that the signal handler is in another thread or something?
Code: Select all
./libretroshare/src/rsserver/rsinit.cc: // SWITCH off the SIGPIPE - kills process on Linux.
./libretroshare/src/rsserver/rsinit.cc: if (0 == sigaction(SIGPIPE, &sigact, NULL))


I tried doing what they said in the gmane thread about checking first SSL_get_shutdown() but it passed that check, executed SSL_shutdown and got again the SIGPIPE crash...
nake
 
Posts: 15
Joined: Fri Sep 05, 2014 5:10 pm

Re: SIGPIPE and crash linux 0.5.5-svn

Postby cave » Thu Feb 26, 2015 3:40 pm

please send your bug and GDB log to cyril -> http://retroshare.sourceforge.net/team.html
cave
 
Posts: 109
Joined: Tue Nov 13, 2012 10:27 pm

Re: SIGPIPE and crash linux 0.5.5-svn

Postby Jenster » Fri Apr 03, 2015 5:28 pm

That's not an error necessarily. SIGPIPE signais are generally properly handled in RetroShare. However, GDB thinks it is an error and allows a halt of the process.
You can either:

"continue" after the process has stopped. rather lame since it WILL happen again..

OR

"handle SIGPIPE noprint nostop" before running/continuing RetroShare under GDB.

Once u do that, u can examine the problem(if it exists) under gdb better.
Jenster
 
Posts: 9
Joined: Sun Oct 12, 2014 5:35 pm

Re: SIGPIPE and crash linux 0.5.5-svn

Postby nake » Fri Apr 03, 2015 5:52 pm

If it happens again I'll try to do what you said.

Thanks for the help.
nake
 
Posts: 15
Joined: Fri Sep 05, 2014 5:10 pm


Return to Technical RetroShare discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron