plauged by seg faults

C

cerr

Well yeah, that's the problem, I've tried using the remote GDB feature
which would work nicely but all the watchdogs prevent me from using
it, once the process halt, my system reboots rightaway....

Disable watchdogs for debugging.  :)
int push(char ***list, char *str, int curlen){
  char **temp;
  int i=0;
  temp = realloc((*list),(curlen+1)*sizeof(*list));

Although it almost certainly doesn't matter, I'm pretty sure you want
sizeof(**list) here for consistency.

I would also say that this function is crying out to be cleaned
up, in a couple of very significant ways.  You should not have the
length be a separate argument; "list" should be of a type such that
you can always do push(list, value); without having to know.
//-------------------------------------------------------
char *pop(char ***list, int *size) {
    if(!*size) return 0;
    char *first = (*list)[0];
    memmove(*list, *list + 1, (*size) * sizeof(**list));
    (*size) --;
    (*list) = realloc(*list, (*size) * sizeof(**list));
    return first;
}

Same issues here -- size tracked elsewhere.

Suggestion (totally untested, etc.):

        struct list {
                struct list *next;
                char *s;
        };

        void push(struct list **l, char *s) {
                struct list *new;
                if (!l)
                        return;
                new = malloc(sizeof(*new));
                new->next = *l;
                new->s = s;
                *l = new;
        }

        char *pop(struct list **l) {
                struct list *old;
                char *s;
                if (!l)
                        return NULL;
                old = *l;
                if (old) {
                        *l = old->next;
                        s = old->s;
                        free(old);
                        return s;
                } else {
                        return NULL;
                }
        }

Usage:
        struct list *l = NULL;
        push(&l, "foo");
        push(&l, "bar");
        pop(&l); /* => "bar" */
        pop(&l); /* => "foo" */
        pop(&l); /* => NULL */

Your current model is HUGELY vulnerable to possible clashes involving
the current length getting out of sync somehow, but you never need it if
you use an actual list.

If you do want to use an array, think about something like this:
        struct list {
                char **data;
                size_t curlen;
                size_t allocated;
        };

        void push(struct list *l, char *s) {
                if (l->curlen >= l->allocated) {
                        char **new = malloc(allocated * 2 * sizeof(*data));
                        if (new) {
                                memcpy(new, data, curlen * sizeof(*data));
                                free(l->data);
                                l->data = new;
                                l->allocated *= 2;
                        } else {
                                assert(!"I wrote an error handler");
                        }
                }
                l->data[l->curlen++] = s;
        }

        char *pop(struct list *l) {
                if (l->curlen > 0) {
                        return l->data[--l->curlen];
                }
        }

(And yeah, this code is probably full of errors.)

This actually makes a whole lot of sense yes!
Great idea and it's so much simpler! :)
Let me try ti implement this!
Ron
 
C

cerr

The watchdog probably has to be initialized at some point during boot
up.  Just find that line and comment it out.  Anyway, I hate to sound
like a nanny about this, but being able to disable the watchdog timer
really is the only sensible way to develop.

Exactly and on top of that i wrote a little KeepAlive application that
is providing the hardware heartbeat so the power supply doesn't
disconnect the power...sweet! :)
 
C

cerr

Exactly and on top of that i wrote a little KeepAlive application that
is providing the hardware heartbeat so the power supply doesn't
disconnect the power...sweet! :)

Okay,

Trying to use remote debugging with gdb, compiled the binary with the -
ggdb3 flag but whatsoever i do not get any clear information on what's
going on. The output i'm seeing is:

(gdb) target remote 192.168.101.55:1100
Remote debugging using 192.168.101.55:1100
0xb7e29aec in ?? ()
(gdb) continue
Continuing.

Program received signal SIGSTOP, Stopped (signal).
0xb7e29aec in ?? ()
(gdb) contiue
Undefined command: "contiue". Try "help".
(gdb) continue
Continuing.

Program received signal SIGPIPE, Broken pipe.
0xb7e29aec in ?? ()
(gdb)

Any clues? :eek: The SIGPIPE signal actually terminated my binary... :eek:
 
M

Moi

      Qstr=pop(&msglist, &locLen);
      syslog(LOG_ERR, "DUBUG: popped succesfully!");
      strncpy(res,Qstr,LOG_BUF_SIZE);
      res[LOG_BUF_SIZE]='\0';

This looks wrong. I think you mean:
        res[LOG_BUF_SIZE-1] = 0;

But you would also mean that your strncpy should copy one character
less.

why would this be LOG_BUF_SIZE-1? I defined the variable like char
res[LOG_BUF_SIZE+2]={0};

Which was discussed upthread; it is very uncommon.
and hence there's space for a null character at the end...
This looks clumsy to me.
It also implies that your strncpy should copy yet one less character.
yes, you're right here, it should be: strncpy(res,Qstr,LOG_BUF_SIZE-1);
then if it didn't copy the last null character to close the string i add
it one element before the last:
res[LOG_BUF_SIZE-1]='\0';
because i need to have enough room for a new line: strcat(res,"\n");
This is ugly. IMHO.
That may be true and i do appreciate the help i'm getting to clean-up
this code.

IMO most people would write something like:
**************/

char res[SOME_SIZE];
int siz, done;
char *data;

data = pop(...);
len = strlen(data); /* or maybe pop() could return the length (maybe by reference)
** , since it already knows it.
*/
if (len >= sizeof res) len = sizeof res -1;

memcpy(res, data, len);
res[len++] = '\n';

done = send( fd, res, len, ...);
if (done != len) ... etc ...

/*************

NOTE: the above code relies at only one place on
the data being nul-terminated. It does not *have*
to be nul-terminated, since send() and write() et.al have
a length argument.

HTH,
AvK
 
S

Squeamizh

Okay,

Trying to use remote debugging with gdb, compiled the binary with the -
ggdb3 flag but whatsoever i do not get any clear information on what's
going on. The output i'm seeing is:

(gdb) target remote 192.168.101.55:1100
Remote debugging using 192.168.101.55:1100
0xb7e29aec in ?? ()
(gdb) continue
Continuing.

Program received signal SIGSTOP, Stopped (signal).
0xb7e29aec in ?? ()
(gdb) contiue
Undefined command: "contiue".  Try "help".
(gdb) continue
Continuing.

Program received signal SIGPIPE, Broken pipe.
0xb7e29aec in ?? ()
(gdb)

Any clues? :eek: The SIGPIPE signal actually terminated my binary... :eek:

I'm not sure, but my guess is that you didn't specify a symbol file.
After the target 'remote command', use 'load' and 'symbol-file'.
Something along the lines of:

load foo.out.elf
symbol-file foo.out.elf

....substitute your actual filename, of course.
 
S

Seebs

Program received signal SIGPIPE, Broken pipe.
0xb7e29aec in ?? ()
(gdb)
Any clues? :eek: The SIGPIPE signal actually terminated my binary... :eek:

This is about 99% likely to not be a C problem. SIGPIPE is what you
get when you try to write data to a pipe that's been closed. What this
usually means is that some OTHER program aborted.

-s
 
D

David Resnick

Okay,

Trying to use remote debugging with gdb, compiled the binary with the -
ggdb3 flag but whatsoever i do not get any clear information on what's
going on. The output i'm seeing is:

(gdb) target remote 192.168.101.55:1100
Remote debugging using 192.168.101.55:1100
0xb7e29aec in ?? ()
(gdb) continue
Continuing.

Program received signal SIGSTOP, Stopped (signal).
0xb7e29aec in ?? ()
(gdb) contiue
Undefined command: "contiue".  Try "help".
(gdb) continue
Continuing.

Program received signal SIGPIPE, Broken pipe.
0xb7e29aec in ?? ()
(gdb)

Any clues? :eek: The SIGPIPE signal actually terminated my binary... :eek:

Could try ignoring it (sigignore) . SIGPIPE may be benign, or may
indicate a problem. Only you/your app knows. e.g. in

cat foo | head -20

cat will get a SIGPIPE as I recall, nothing bad happening.

-David
 
C

cerr

This is about 99% likely to not be a C problem.  SIGPIPE is what you
get when you try to write data to a pipe that's been closed.  What this
usually means is that some OTHER program aborted.

But when I ignore the SIGPIPE in gdb i get the message and then it
tells me that app exited because of SIGPIPE. And what would "some
other" program may be? My app doesn't depend on anything really...
 
C

cerr

I'm not sure, but my guess is that you didn't specify a symbol file.
After the target 'remote command', use 'load' and 'symbol-file'.
Something along the lines of:

load foo.out.elf
symbol-file foo.out.elf

Hi Squeamizh,

Ok, I used "load /my/binary/on/the/local/fs" after "target remote" and
the app on my target actually terminated if i try "symbol-file /my/
binary/on/the/local/fs" only - i don't get any change on the report
when it terminates on SIGPIPE. :( How do I get the app still going
after the load?

Thanks,
Ron
 
C

cerr

Hi There,
My daemon app keeps terminating and i'm trying to figure out why and
where. I have a good idea tho. I'm using a push - pop FIFO system for
log messages. I have a syslog message after the push and after the pop
function and see both appearingh all the time and hence i think that
both, push() and pop() works fine. However, the messages get popped
off in a thread from where i send the data off. I'm using following
code:
pthread_mutex_lock(&log_mtx);
      Qstr=pop(&msglist, &locLen);
      syslog(LOG_ERR, "DUBUG: popped succesfully!");
      strncpy(res,Qstr,LOG_BUF_SIZE);
      res[LOG_BUF_SIZE]='\0';
      strcat(res,"\n");
      pthread_mutex_unlock(&log_mtx);
      if (log_sock>-1) {
        sndlen=strlen(res);
        reclen=send(log_sock, res, sndlen, 0);
        if (reclen != sndlen) {
          if (reclen==-1){
            syslog(LOG_ERR, "nlog: send failed...,errno: %s!", strerror
( errno ));
          }
          syslog(LOG_ERR, "nlog: \"%s\" not sent, strlen(%d) - sent %d",res,
sndlen, reclen);
        }
        else {
          syslog(LOG_ERR, "DEBUG: sent okay, receive ack");
The last message I see in syslog before my app crashes is "DUBUG:
popped succesfully!"
Now the declaration of those variables are as follows:
  char res[LOG_BUF_SIZE+2]={0};
  char *Qstr;
  int locLen;
  int sndlen;
while msglist is from type char** and QLen from type int and declared
globally.
LOG_BUF_SIZE is a define and set to 512.
Does anyone have a clue where my app is terminating and or should i be
looking somewhere else all together? The system worked fine before i
implemented this new FIFO system...
Thanks for hints and suggestions!
Ron
I'd check the return value of pop.  Is it a reasonable pointer?  NULL?
Yep as Beej had suggested, I included a check for NULL:
      if (Qstr!=NULL)
        syslog(LOG_ERR, "DUBUG: popped succesfully!");
      else {
        syslog(LOG_ERR, "DUBUG: popped not succesful!");
        break;
      }
If that doesn't solve it, I'd try tools, like valgrind.  Or running in
a debugger, or enabling cores.
will try to use valgrind - don't know if it will run on my embedded
platform tho...
I just compiled valgrind on our dev system but no way i'll be able to
copy it onto our target system as the /opt/valgrind-3.2.3 directory is
81MB big... :(... ah, i'm getting desperate.... what can i do?
Other hints, recommodations and suggestions are highly appreciated!
Thanks!
Ron

I assumed you were on a linux flavor.  Enabling cores means usually
setting ulimit to allow cores to dump on fatal signals, probably not
relevant to your embedded system.  

How do you assume that? :eek:
I would like to dump cores, I set "ulimit -a" but I never see a core
dumped anywhere, what file would i be looking for?
Umm, add more syslogs, repeat as
needed, to narrow down your problem seems like a good bet.  You should
be able to figure out exactly what bad pointer causes the segfault,
and trace the problem that way.

It doesn't seem to be a segfault but a SIGPIPE that causes my program
to crash, gdb says:

Program received signal SIGPIPE, Broken pipe.

Program terminated with signal SIGPIPE, Broken pipe.
The program no longer exists.
(gdb)
You could crash on push if the malloc failed, which I assume is
possible on your limited memory embedded system.  You could be messed
up on pop if somehow a shrinking realloc fails.

# free

shows me plenty of free memory...
 
D

David Resnick

Hi There,
My daemon app keeps terminating and i'm trying to figure out why and
where. I have a good idea tho. I'm using a push - pop FIFO system for
log messages. I have a syslog message after the push and after the pop
function and see both appearingh all the time and hence i think that
both, push() and pop() works fine. However, the messages get popped
off in a thread from where i send the data off. I'm using following
code:
pthread_mutex_lock(&log_mtx);
      Qstr=pop(&msglist, &locLen);
      syslog(LOG_ERR, "DUBUG: popped succesfully!");
      strncpy(res,Qstr,LOG_BUF_SIZE);
      res[LOG_BUF_SIZE]='\0';
      strcat(res,"\n");
      pthread_mutex_unlock(&log_mtx);
      if (log_sock>-1) {
        sndlen=strlen(res);
        reclen=send(log_sock, res, sndlen, 0);
        if (reclen != sndlen) {
          if (reclen==-1){
            syslog(LOG_ERR, "nlog: send failed...,errno: %s!", strerror
( errno ));
          }
          syslog(LOG_ERR, "nlog: \"%s\" not sent, strlen(%d) - sent %d",res,
sndlen, reclen);
        }
        else {
          syslog(LOG_ERR, "DEBUG: sent okay, receive ack");
The last message I see in syslog before my app crashes is "DUBUG:
popped succesfully!"
Now the declaration of those variables are as follows:
  char res[LOG_BUF_SIZE+2]={0};
  char *Qstr;
  int locLen;
  int sndlen;
while msglist is from type char** and QLen from type int and declared
globally.
LOG_BUF_SIZE is a define and set to 512.
Does anyone have a clue where my app is terminating and or should i be
looking somewhere else all together? The system worked fine before i
implemented this new FIFO system...
Thanks for hints and suggestions!
Ron
I'd check the return value of pop.  Is it a reasonable pointer?  NULL?
Yep as Beej had suggested, I included a check for NULL:
      if (Qstr!=NULL)
        syslog(LOG_ERR, "DUBUG: popped succesfully!");
      else {
        syslog(LOG_ERR, "DUBUG: popped not succesful!");
        break;
      }
If that doesn't solve it, I'd try tools, like valgrind.  Or running in
a debugger, or enabling cores.
will try to use valgrind - don't know if it will run on my embedded
platform tho...
I just compiled valgrind on our dev system but no way i'll be able to
copy it onto our target system as the /opt/valgrind-3.2.3 directory is
81MB big... :(... ah, i'm getting desperate.... what can i do?
Other hints, recommodations and suggestions are highly appreciated!
Thanks!
Ron
I assumed you were on a linux flavor.  Enabling cores means usually
setting ulimit to allow cores to dump on fatal signals, probably not
relevant to your embedded system.  

How do you assume that? :eek:
I would like to dump cores, I set "ulimit -a" but I never see a core
dumped anywhere, what file would i be looking for?

ulimit -c unlimited

may do what you want. Cores often dump where the executable is, or in
some configurable directory.
It doesn't seem to be a segfault but a SIGPIPE that causes my program
to crash, gdb says:

Program received signal SIGPIPE, Broken pipe.

Program terminated with signal SIGPIPE, Broken pipe.
The program no longer exists.
(gdb)




# free

shows me plenty of free memory...

Dunno what to suggest, other than add syslogs until you feel you
understand

-David
 
M

Michael Foukarakis

Hi There,
My daemon app keeps terminating and i'm trying to figure out why and
where. I have a good idea tho. I'm using a push - pop FIFO system for
log messages. I have a syslog message after the push and after the pop
function and see both appearingh all the time and hence i think that
both, push() and pop() works fine. However, the messages get popped
off in a thread from where i send the data off. I'm using following
code:
pthread_mutex_lock(&log_mtx);
      Qstr=pop(&msglist, &locLen);
      syslog(LOG_ERR, "DUBUG: popped succesfully!");
      strncpy(res,Qstr,LOG_BUF_SIZE);
      res[LOG_BUF_SIZE]='\0';
      strcat(res,"\n");
      pthread_mutex_unlock(&log_mtx);
      if (log_sock>-1) {
        sndlen=strlen(res);
        reclen=send(log_sock, res, sndlen, 0);
        if (reclen != sndlen) {
          if (reclen==-1){
            syslog(LOG_ERR, "nlog: send failed...,errno: %s!", strerror
( errno ));
          }
          syslog(LOG_ERR, "nlog: \"%s\" not sent, strlen(%d) - sent %d",res,
sndlen, reclen);
        }
        else {
          syslog(LOG_ERR, "DEBUG: sent okay, receive ack");
The last message I see in syslog before my app crashes is "DUBUG:
popped succesfully!"
Now the declaration of those variables are as follows:
  char res[LOG_BUF_SIZE+2]={0};
  char *Qstr;
  int locLen;
  int sndlen;
while msglist is from type char** and QLen from type int and declared
globally.
LOG_BUF_SIZE is a define and set to 512.
Does anyone have a clue where my app is terminating and or should i be
looking somewhere else all together? The system worked fine before i
implemented this new FIFO system...
Thanks for hints and suggestions!
Ron
I'd check the return value of pop.  Is it a reasonable pointer?  NULL?

Yep as Beej had suggested, I included a check for NULL:
      if (Qstr!=NULL)
        syslog(LOG_ERR, "DUBUG: popped succesfully!");
      else {
        syslog(LOG_ERR, "DUBUG: popped not succesful!");
        break;
      }
If that doesn't solve it, I'd try tools, like valgrind.  Or running in
a debugger, or enabling cores.

will try to use valgrind - don't know if it will run on my embedded
platform tho...
Debugger unfortunately will not be an option.... enabling cores - what
do you mean?

Thanks!
Ron

A debugger's not an option? What is this, 1980? Have you thought about
disabling the watchdogs?
 
C

cerr

Hi There,
My daemon app keeps terminating and i'm trying to figure out why and
where. I have a good idea tho. I'm using a push - pop FIFO system for
log messages. I have a syslog message after the push and after the pop
function and see both appearingh all the time and hence i think that
both, push() and pop() works fine. However, the messages get popped
off in a thread from where i send the data off. I'm using following
code:
pthread_mutex_lock(&log_mtx);
      Qstr=pop(&msglist, &locLen);
      syslog(LOG_ERR, "DUBUG: popped succesfully!");
      strncpy(res,Qstr,LOG_BUF_SIZE);
      res[LOG_BUF_SIZE]='\0';
      strcat(res,"\n");
      pthread_mutex_unlock(&log_mtx);
      if (log_sock>-1) {
        sndlen=strlen(res);
        reclen=send(log_sock, res, sndlen, 0);
        if (reclen != sndlen) {
          if (reclen==-1){
            syslog(LOG_ERR, "nlog: send failed...,errno: %s!", strerror
( errno ));
          }
          syslog(LOG_ERR, "nlog: \"%s\" not sent, strlen(%d) - sent %d",res,
sndlen, reclen);
        }
        else {
          syslog(LOG_ERR, "DEBUG: sent okay, receive ack");
The last message I see in syslog before my app crashes is "DUBUG:
popped succesfully!"
Now the declaration of those variables are as follows:
  char res[LOG_BUF_SIZE+2]={0};
  char *Qstr;
  int locLen;
  int sndlen;
while msglist is from type char** and QLen from type int and declared
globally.
LOG_BUF_SIZE is a define and set to 512.
Does anyone have a clue where my app is terminating and or should i be
looking somewhere else all together? The system worked fine before i
implemented this new FIFO system...
Thanks for hints and suggestions!
Ron
I'd check the return value of pop.  Is it a reasonable pointer?  NULL?
Yep as Beej had suggested, I included a check for NULL:
      if (Qstr!=NULL)
        syslog(LOG_ERR, "DUBUG: popped succesfully!");
      else {
        syslog(LOG_ERR, "DUBUG: popped not succesful!");
        break;
      }
will try to use valgrind - don't know if it will run on my embedded
platform tho...
Debugger unfortunately will not be an option.... enabling cores - what
do you mean?
Thanks!
Ron

A debugger's not an option? What is this, 1980? Have you thought about
disabling the watchdogs?

Yes, well I've gotten overthis, disabling the watchdogs alone wouldn't
help, I needed to write a little KeepAlive application to provide a
heartbeat to the power supply so this would not cut the power when the
heartbeat isn't provided by my "main app" (cause it's stopped in a
debugger) - so we're good if you add 30 years, it's 2010 ;)
 
C

cerr

Hi There,
My daemon app keeps terminating and i'm trying to figure out why and
where. I have a good idea tho. I'm using a push - pop FIFO system for
log messages. I have a syslog message after the push and after the pop
function and see both appearingh all the time and hence i think that
both, push() and pop() works fine. However, the messages get popped
off in a thread from where i send the data off. I'm using following
code:
pthread_mutex_lock(&log_mtx);
      Qstr=pop(&msglist, &locLen);
      syslog(LOG_ERR, "DUBUG: popped succesfully!");
      strncpy(res,Qstr,LOG_BUF_SIZE);
      res[LOG_BUF_SIZE]='\0';
      strcat(res,"\n");
      pthread_mutex_unlock(&log_mtx);
      if (log_sock>-1) {
        sndlen=strlen(res);
        reclen=send(log_sock, res, sndlen, 0);
        if (reclen != sndlen) {
          if (reclen==-1){
            syslog(LOG_ERR, "nlog: send failed...,errno: %s!", strerror
( errno ));
          }
          syslog(LOG_ERR, "nlog: \"%s\" not sent, strlen(%d) - sent %d",res,
sndlen, reclen);
        }
        else {
          syslog(LOG_ERR, "DEBUG: sent okay, receive ack");
The last message I see in syslog before my app crashes is "DUBUG:
popped succesfully!"
Now the declaration of those variables are as follows:
  char res[LOG_BUF_SIZE+2]={0};
  char *Qstr;
  int locLen;
  int sndlen;
while msglist is from type char** and QLen from type int and declared
globally.
LOG_BUF_SIZE is a define and set to 512.
Does anyone have a clue where my app is terminating and or should i be
looking somewhere else all together? The system worked fine before i
implemented this new FIFO system...
Thanks for hints and suggestions!
Ron
I'd check the return value of pop.  Is it a reasonable pointer?  NULL?
Yep as Beej had suggested, I included a check for NULL:
      if (Qstr!=NULL)
        syslog(LOG_ERR, "DUBUG: popped succesfully!");
      else {
        syslog(LOG_ERR, "DUBUG: popped not succesful!");
        break;
      }
If that doesn't solve it, I'd try tools, like valgrind.  Or running in
a debugger, or enabling cores.
will try to use valgrind - don't know if it will run on my embedded
platform tho...
I just compiled valgrind on our dev system but no way i'll be able to
copy it onto our target system as the /opt/valgrind-3.2.3 directory is
81MB big... :(... ah, i'm getting desperate.... what can i do?
Other hints, recommodations and suggestions are highly appreciated!
Thanks!
Ron
I assumed you were on a linux flavor.  Enabling cores means usually
setting ulimit to allow cores to dump on fatal signals, probably not
relevant to your embedded system.  
How do you assume that? :eek:
I would like to dump cores, I set "ulimit -a" but I never see a core
dumped anywhere, what file would i be looking for?

ulimit -c unlimited

may do what you want.  Cores often dump where the executable is, or in
some configurable directory.






It doesn't seem to be a segfault but a SIGPIPE that causes my program
to crash, gdb says:
Program received signal SIGPIPE, Broken pipe.
Program terminated with signal SIGPIPE, Broken pipe.
The program no longer exists.
(gdb)
shows me plenty of free memory...

Dunno what to suggest, other than add syslogs until you feel you
understand
That's exactly where desperation brought me :$
And I figured out that my send() command seemingly is bringing my app
down (and now SIGPIPE would make sense too)
the code that bails out looks like:
if (log_sock>-1) {
sndlen=strlen(res);
syslog(LOG_ERR, "_run_logger(): got strlen(res):%d, log_sock:
%d",sndlen, log_sock);
reclen=send(log_sock, res, sndlen, 0);
syslog(LOG_ERR, "_run_logger(): sent \'%s\"",res);
now how can i verify if my socket is still writeable? Must work with
select() somehow. Anyone?
Thanks,
Ron
 
K

Keith Thompson

cerr said:
And I figured out that my send() command seemingly is bringing my app
down (and now SIGPIPE would make sense too)
the code that bails out looks like:
if (log_sock>-1) {
sndlen=strlen(res);
syslog(LOG_ERR, "_run_logger(): got strlen(res):%d, log_sock:
%d",sndlen, log_sock);
reclen=send(log_sock, res, sndlen, 0);
syslog(LOG_ERR, "_run_logger(): sent \'%s\"",res);
now how can i verify if my socket is still writeable? Must work with
select() somehow. Anyone?

Standard C doesn't have sockets, select(), or send().

Aside from whether discussion of non-standard featuers is topical here
or not, you're really likely to get better help in a different
newsgroup, likely comp.unix.programmer.
 
C

cerr

[...]
And I figured out that my send() command seemingly is bringing my app
down (and now SIGPIPE would make sense too)
the code that bails out looks like:
      if (log_sock>-1) {
   sndlen=strlen(res);
   syslog(LOG_ERR, "_run_logger(): got strlen(res):%d, log_sock:
%d",sndlen, log_sock);
   reclen=send(log_sock, res, sndlen, 0);
   syslog(LOG_ERR, "_run_logger(): sent \'%s\"",res);
now how can i verify if my socket is still writeable? Must work with
select() somehow. Anyone?

Standard C doesn't have sockets, select(), or send().

Aside from whether discussion of non-standard featuers is topical here
or not, you're really likely to get better help in a different
newsgroup, likely comp.unix.programmer.

Okay, thanks for redirecting me. I'll try my luck there...
 
L

lawrence.jones

cerr said:
That's exactly where desperation brought me :$
And I figured out that my send() command seemingly is bringing my app
down (and now SIGPIPE would make sense too)
the code that bails out looks like:
if (log_sock>-1) {
sndlen=strlen(res);
syslog(LOG_ERR, "_run_logger(): got strlen(res):%d, log_sock:
%d",sndlen, log_sock);
reclen=send(log_sock, res, sndlen, 0);
syslog(LOG_ERR, "_run_logger(): sent \'%s\"",res);
now how can i verify if my socket is still writeable? Must work with
select() somehow. Anyone?

Most likely, you want to ignore SIGPIPE, which will cause send to return
-1 in that case. But comp.unix.programmer is definitely a better forum.
 
D

David Thompson

It doesn't seem to be a segfault but a SIGPIPE that causes my program
to crash, gdb says:

Program received signal SIGPIPE, Broken pipe.

Program terminated with signal SIGPIPE, Broken pipe.
The program no longer exists.
(gdb)

On at least some socket stacks, send() to a TCP socket that's become
disconnected gives SIGPIPE (not just write() to an actual pipe).

Assuming you don't actually need SIGPIPE anywhere else in your
program, signal(SIGPIPE,SIG_IGN) at startup, and then see what errno
you get on the send() attempt; it's likely to be informative.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,767
Messages
2,569,570
Members
45,045
Latest member
DRCM

Latest Threads

Top