From: lcargill99@comcast.com   
      
   Barry Margolin wrote:   
   > 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.   
   >   
      
      
   This seems to indicate that SIGPIPE can be disabled. The socket   
   then returns EPIPE.   
   http://stackoverflow.com/questions/108183/how-to-prevent-sigpipe   
   -or-handle-them-properly   
      
   Fix is:   
   --- EXCERPT ---   
   int set = 1;   
   setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, (void *)&set, sizeof(int));   
      
   --- END EXCERPT ---   
      
   I'll report back tomorrow after trying it.   
      
   Thanks everyone.   
      
   --   
   Les Cargill   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)