Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > plauged by seg faults

Reply
Thread Tools

plauged by seg faults

 
 
Beej Jorgensen
Guest
Posts: n/a
 
      01-06-2010
On 01/05/2010 02:26 PM, cerr wrote:
> On Jan 5, 11:50 am, Beej Jorgensen <(E-Mail Removed)> wrote:
>> Based on the information you've given, I'd suspect that pop() was
>> returning an invalid pointer or NULL...?

> Yup, added a
> if (Qstr!=NULL)
> syslog(LOG_ERR, "DUBUG: popped succesfully!");
> else {
> syslog(LOG_ERR, "DUBUG: popped not succesful!");
> break; /* the break would break back to the thread's while(1) loop*/
> }


Did that "fix" it?

> Here it says that it would say smthng like "Segmentation fault (core
> dumped)" but i don't even get ANY back log on the screen cause the app
> is running in daemon mode...


This is better asked on comp.unix.programmer, but you can use
setrlimit() to unlimit the writing of core files. If it's a daemon, it
should be cwd /, but it might not be able to write the file there
depending on which user its running as... but I've never tried any of
this with a daemon so YMMV.

-Beej

 
Reply With Quote
 
 
 
 
Moi
Guest
Posts: n/a
 
      01-06-2010
On Tue, 05 Jan 2010 11:40:30 -0800, cerr wrote:

> 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';


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.

> strcat(res,"\n");


This looks clumsy to me.
It also implies that your strncpy should copy yet one less character.

> pthread_mutex_unlock(&log_mtx);
> if (log_sock>-1) {


You could have tested this earlier and bailed out ASAP.

> sndlen=strlen(res);


This is ugly. IMHO.

HTH,
AvK


 
Reply With Quote
 
 
 
 
David Resnick
Guest
Posts: n/a
 
      01-06-2010
On Jan 5, 5:43*pm, cerr <(E-Mail Removed)> wrote:
> On Jan 5, 2:30*pm, cerr <(E-Mail Removed)> wrote:
>
>
>
> > On Jan 5, 1:23*pm, David Resnick <(E-Mail Removed)> wrote:

>
> > > On Jan 5, 2:40*pm, cerr <(E-Mail Removed)> wrote:

>
> > > > 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. 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.

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.

-David
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-06-2010
Moi <(E-Mail Removed)> writes:

> On Tue, 05 Jan 2010 11:40:30 -0800, cerr wrote:
>
>> 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';

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


Yes, it *looks* wrong, but...

> But you would also mean that your strncpy should copy one character less.
>
>> strcat(res,"\n");

>
> This looks clumsy to me.
> It also implies that your strncpy should copy yet one less
> character.


res is declared to be BUF_SIZE+2 characters long in code now snipped.
The real problem for anyone reading this is the BUF_SIZE is
miss-named. It is not the size of the buffer.

<snip>
--
Ben.
 
Reply With Quote
 
Squeamizh
Guest
Posts: n/a
 
      01-06-2010
On Jan 5, 4:20*pm, Seebs <(E-Mail Removed)> wrote:
> On 2010-01-05, cerr <(E-Mail Removed)> wrote:
>
> > 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. *


This is the real answer for the OP. Even if you solve this problem
without gdb, you'll run into another unsolvable problem sooner or
later. Disabling the watchdog timer for debugging is mandatory.
 
Reply With Quote
 
Moi
Guest
Posts: n/a
 
      01-06-2010
On Wed, 06 Jan 2010 15:01:12 +0000, Ben Bacarisse wrote:

> Moi <(E-Mail Removed)> writes:
>
>> On Tue, 05 Jan 2010 11:40:30 -0800, cerr wrote:
>>

>
>>> 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';

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

>
> Yes, it *looks* wrong, but...
>
>
>
> res is declared to be BUF_SIZE+2 characters long in code now snipped.
> The real problem for anyone reading this is the BUF_SIZE is miss-named.
> It is not the size of the buffer.


Yes, I could not agree more.
What the OP also does wrong is putting the declaration of res[]
_after_ its use.
This is disastrous for lazy people like me, who bail out on the first
spotted error, or the first page with (assumed) errors on it.

Also, I think the usage of the mutex-locks is rather strange.
I would expect the locks to be _inside_ the push() pop() functions.
The locks also do not preserves the order of the messages, if that would
be important to the OP.

AvK
 
Reply With Quote
 
cerr
Guest
Posts: n/a
 
      01-06-2010
On Jan 6, 7:24*am, Squeamizh <(E-Mail Removed)> wrote:
> On Jan 5, 4:20*pm, Seebs <(E-Mail Removed)> wrote:
>
> > On 2010-01-05, cerr <(E-Mail Removed)> wrote:

>
> > > 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. *

>
> This is the real answer for the OP. *Even if you solve this problem
> without gdb, you'll run into another unsolvable problem sooner or
> later. *Disabling the watchdog timer for debugging is mandatory.


Exactly but I don't know yet how i can do this, need to figure that
out first, it seems as if there's several processes that depend on
each other and if one fails, the system reboots...
 
Reply With Quote
 
cerr
Guest
Posts: n/a
 
      01-06-2010
On Jan 6, 4:09*am, Moi <(E-Mail Removed)> wrote:
> On Tue, 05 Jan 2010 11:40:30 -0800, cerr wrote:
> > 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';

>
> 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};
and hence there's space for a null character at the end...
>
> > * * * strcat(res,"\n");

>
> 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");

would this do it you think?

>
> > * * * pthread_mutex_unlock(&log_mtx);
> > * * * if (log_sock>-1) {

>
> You could have tested this earlier and bailed out ASAP.

check if the siocket is alright...yeah i can move this further up.
>
> > * *sndlen=strlen(res);

>
> This is ugly. IMHO.

That may be true and i do appreciate the help i'm getting to clean-up
this code.

Thanks a lot!
Ron

 
Reply With Quote
 
Squeamizh
Guest
Posts: n/a
 
      01-06-2010
On Jan 6, 8:23*am, cerr <(E-Mail Removed)> wrote:
> On Jan 6, 7:24*am, Squeamizh <(E-Mail Removed)> wrote:
>
> > On Jan 5, 4:20*pm, Seebs <(E-Mail Removed)> wrote:

>
> > > On 2010-01-05, cerr <(E-Mail Removed)> wrote:

>
> > > > 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. *

>
> > This is the real answer for the OP. *Even if you solve this problem
> > without gdb, you'll run into another unsolvable problem sooner or
> > later. *Disabling the watchdog timer for debugging is mandatory.

>
> Exactly but I don't know yet how i can do this, need to figure that
> out first, it seems as if there's several processes that depend on
> each other and if one fails, the system reboots...


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.
 
Reply With Quote
 
cerr
Guest
Posts: n/a
 
      01-06-2010
On Jan 6, 8:03*am, Moi <(E-Mail Removed)> wrote:
> On Wed, 06 Jan 2010 15:01:12 +0000, Ben Bacarisse wrote:
> > Moi <(E-Mail Removed)> writes:

>
> >> On Tue, 05 Jan 2010 11:40:30 -0800, cerr wrote:

>
> >>> 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';

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

>
> > Yes, it *looks* wrong, but...

>
> > res is declared to be BUF_SIZE+2 characters long in code now snipped.
> > The real problem for anyone reading this is the BUF_SIZE is miss-named.
> > It is not the size of the buffer.

>
> Yes, I could not agree more.
> What the OP also does wrong is putting the declaration of res[]
> _after_ its use.
> This is disastrous for lazy people like me, who bail out on the first
> spotted error, or the first page with (assumed) errors on it.
>
> Also, I think the usage of the mutex-locks is rather strange.
> I would expect the locks to be _inside_ the push() pop() functions.
> The locks also do not preserves the order of the messages, if that would
> be important to the OP.


Hm, why would you put them inside? I pout them outside so i can hold
the pop() and push() functions stand-alone, so they can be used in
multi threaded environments but if it's single threaded you don't
require mutexes, eh?
Also why would the order of messages not be preserved? i don't
understand...

Ron

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Many differerent problems with seg faults. stephenma7@hotmail.com C++ 4 02-15-2005 04:01 AM
malloc creates seg faults? Berk Birand C++ 7 02-14-2005 10:29 PM
Re: malloc creates seg faults? Sharad Kala C++ 2 02-14-2005 05:20 AM
Getting seg faults in destructors. Possibly a newbie problem. Andrew King C++ 1 04-07-2004 05:09 PM
bsddb module bug?: doesn't release locks and seg faults Jane Austine Python 0 08-14-2003 03:12 AM



Advertisments