On Tue, Sep 08, 2015 at 05:03:56PM +0530, shirish शिरीष wrote: > Hi Carsten, > Sorry for being a nuisance. Didn't mean to be. I actually had another > session running and this is what it showed (again) . I do have it's > backtrace but am hesitant. > > Program received signal SIGPIPE, Broken pipe. > [Switching to Thread 0x7fffdeafe700 (LWP 3383)] > 0x00007ffff7bcdd8f in __libc_send (fd=68, > buf=buf@entry=0x7fffbcf46000, n=n@entry=53, flags=flags@entry=0) at > ../sysdeps/unix/sysv/linux/x86_64/send.c:31 > 31 ../sysdeps/unix/sysv/linux/x86_64/send.c: No such file or directory. > > This surely means that the program (Broken pipe) bit. > > <snipped> > > Anyways, will get back to you will the file. I'm sorry it will be big > as I'm also not an expert in reading gdb files.
SIGPIPE isn't a segfault. You get (or better say the program) is getting this interrupt if the socket it's trying to write to is already closed. This indicated some problems on the TCP/IP stack. http://stackoverflow.com/questions/8369506/why-does-sigpipe-exist That can simply happen because the socket was closed by the remote site, your local LAN/WLAN/UMTS connection is flapping or maybe some race condition within the source is provoking this. So if you suspect the source is wrong then first you need to know which exact part of the source code is responsible, look into the gdb log, it will tell you. A other log that shows the network action on the protocol stack can be helpful. It's described in the wiki how to do that. Next step I would do is to do a git blame on the respective source to see if there really is something changed but I don't expect this. But if something is changed you have to understand what and why. But I wouldn't do much here, you are talking about a beta version, there can be some parts not that stable. Regards Carsten
