From: barmar@alum.mit.edu   
      
   In article ,   
    Les Cargill  wrote:   
      
   > Jorgen Grahn wrote:   
   > > On Thu, 2013-02-14, Les Cargill wrote:   
   > >> Rick Jones wrote:   
   > > ...   
   > >>> What do you mean by send() "crashes?"   
   > >>   
   > >> The program exits without complaint.   
   > >   
   > > That's another way of saying "send() does not crash but returns, and   
   > > my own program logic, which I haven't shown you, does something which   
   > > end with an exit(0) or a return 0 from main()".   
   > >   
   >   
   > (dots are not varargs stuff in this, but rather ellipses for English   
   > purposes).   
   >   
   > I have a construct (macro) called "trace()" that puts stuff out the   
   > console using printf(...,__LINE__) ,  fflush() and usleep() in   
   > that order. I've yet to catch it not generating output. Of course it's   
   > invasive, but it's for finding crashes...   
   >   
   > I bracketed the send() call with those. The first one is seen; the   
   > second one is not.   
   >   
   > trace();   
   > ... = send(...);   
   > trace();   
   >   
   > Never say never, but I am pretty confident that the send was   
   > the last thing that happened. The console is a serial port at 115kbit,   
   > and I set the usleep() to be twice the number of character times   
   > of the previous printf();   
   >   
   > > The socket questions (which I didn't read) are still relevant I guess,   
   > > but only you can tell what really happens in your program, and what   
   > > really does happen when you call send().  The easiest way may be to   
   > > get strace(1) to run on your system,   
   >   
   > Agreed; it might be time to try to get strace() to work on this   
   > system. It's BusyBox/ash so I've been avoiding that...   
   >   
   > > and use it to get a trace of the   
   > > system calls.   
   > >   
   > > /jORGEN   
   > >   
      
   Sounds like the program is being terminated by a SIGPIPE signal. Some   
   shells don't report this as an error, because it's common in pipelines,   
   e.g.   
      
   somecommand | head   
      
   When head finishes printing the first 10 lines it exits, and somecommand   
   will soon get a SIGPIPE when it tries to write more stuff to the pipe.   
   "Broken pipe" messages for this are usually not interesting to the user,   
   so they're suppressed.   
      
   --   
   Barry Margolin   
   Arlington, MA   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)