It is currently Wed, 22 May 2019 08:40:32 GMT



 
Author Message
 Strange error with pthreads
I'm having a strange error with FreeBSD that I can't figure out. I
wrote a multi-threaded server that executes an infinity loop and for
each accept connection it launchs a new thread do serve the client.
There's no point where you can exit the main loop. Sometimes the
program exit and generates no core dump, so it seems that the program
exited normally.

Does anyone has some idea of what can I do to figure out what's
happening?

Regards,

Pedro Paulo Jr.



 Sun, 04 Jan 2004 02:11:16 GMT   
 Strange error with pthreads
Pedro Paulo Oliveira jr wrote:

Use a de{*filter*} such as xxgdb, gdb.

Not all catastrophic errors cause a core dump.
You could also check the return codes for every
call and use fprintf(stderr, " ...) to report
the error.

--
My answers are not exhautive treatises and I may have left out important
notes which I am sure  others will  comment  on in the  future. There is
always more than one way to skin a cat. If you want a  complete  list of
options please Read The Fine Man[ual] Page.



 Sun, 04 Jan 2004 05:21:09 GMT   
 Strange error with pthreads

I think gdb or xxgdb is not useful in this case since the error occurs
randomly maybe due to some strange race condition in the threads. Does
anyone know some tool to debug this?

PPJ



 Sun, 04 Jan 2004 23:32:16 GMT   
 Strange error with pthreads
p...@speedcomm.com.br (Pedro Paulo Oliveira jr) wrote in message <news:c93cf96e.0107180732.69f777ff@posting.google.com>...

I'm posting the main loop to of the server. Note that the error occurs
randomly. And I'm detaching the thread.

unsigned ListenFunc()
{
        SOCKET          socketClient;
        struct sockaddr SockAddr;
        LPREQUEST       lpReq;
        unsigned int    nLen;
        DWORD           dwRet;
        int             pid;
        FILE    *       log_err;

        pthread_t  tid;             /* variable to hold thread ID */

        //
        // Loop forever accepting connections
        //
        while(1)
        {
                //
                // Block on accept()
                //
                nLen = sizeof(struct sockaddr);
                socketClient = accept(listenSocket, &SockAddr, &nLen);
                if (socketClient == -1)
                {
                        log_err = fopen ("Errlog.txt","at");
                        if (log_err != NULL) {
                                fprintf (log_err,"%s\n",strerror(errno));
                                fclose (log_err);
                        }
                        continue;
                }

                //
                // Allocate struct for client and fill in defaults
                //
                lpReq = (struct tagREQUEST*)malloc(sizeof(REQUEST));
                if (lpReq == NULL)
                {
                        continue;
                }
                lpReq->Socket = socketClient;

                //
                // Start a client thread to handle this request
                //
                pthread_create (&tid,NULL,ClientFunc,(void*)lpReq);
                pthread_detach (tid);
        }
        log_err = fopen ("Errlog.txt","at");        
        if (log_err != NULL) {
                fprintf (log_err,"Error exit infinity loop! It should not reach
here\n");
                fclose (log_err);
        }
        return 0;

The system used is an 1Ghz AMD Athlon running FreeBSD 4.3 with 256 MB
of RAM.



 Mon, 05 Jan 2004 20:30:54 GMT   
 Strange error with pthreads
I have always used printf statements in my programs to debug programs.
I felt kind of embarressed that I never got around to learning a
debugging tool.  Then I read that Linus Torvolds also uses printf rather
than a de{*filter*}, so I felt in good company.

Here is what I would do.  Put something like this in your code:

pthread_mutex_t print_mutex = PTHREAD_MUTEX_INITIALIZER;
void here(int n) {
  pthread_mutex_lock(&print_mutex);
  fprintf(stderr,"Here %d\n",n);
  fflush(stderr);
  pthread_mutex_unlock(&print_mutex);

The fflush is probbaly unnecessary because I think that stderr is
usually unbuffered, but it cannot do any harm.  

Then pepper
here(1);
here(2);
here(3);
round various parts of the program (in the threads as well as the main
program).  Then do:

server_program >& server.log

and look at server.log after the program stops to see where the problem
is.  When you have a rough idea where the problem is, you can narrow it
down by adding more here statements.

I have found this method to be very successful in debugging my programs.

--
Stephen Montgomery-Smith
step...@math.missouri.edu
http://www.**-**.com/ ~stephen



 Mon, 05 Jan 2004 23:20:23 GMT   
 Strange error with pthreads
Pedro Paulo Oliveira jr wrote:

Here you have an open socket, you take a chance of using up your file
descriptors
if you have a memory leak within this or other applications.

                        close(socketClient);
                        syslog(..., "Resource allocation failure");
                        continue;

You want to ensure that you are closing this socket within the thread.

This is perfectly acceptable. You can also use
pthread_detach(pthread_self());
at the start of the thread which I think is more of a standard way of
doing
it. On a multiprocessor machine, it would make the loop slightly faster
and allow more clients to be attended to more quickly. The more code
you shove into the thread the better. Just my preference.

You can also say
        phtread_create(...,(void *)socketClient);

and in the ClientFunc say

void *ClientFunc(void *ptr)
        {
        int fd = (int)ptr;

        ...

        close(fd);

        return NULL;
        }

This would avoid the malloc issue, since there seems to be no other
members in use.
You also do not have to worry about free since the space is allocated on
the
stack and gets cleaned up on exit of ClientFunc.

I assume you are calling free within the thread. I had a similiar
situation on
Linux and I tracked it down to the free call within the thread. It would
randomly segfault on me while freeing memory. Check for this by putting
fprintf's around the free's (you are freeing the memory?). I ending up
pulling
most of my hair out and then went to a fixed length "queue" (for lack of
a better
word). If I had more "connections" than structures, I "dropped" the
connection.
If you expect to have a scenario, similiar to most, were the client
makes a
request and the server processes it, responds, and that is that. A fixed
number of structures can work. It is not very scalable, but you could
make the
length of the queue a command line argument so that it could be tuned.
If
the structure is small, (4 bytes, it looks like in this case) you can
make it
really huge, like 10240 = 40k in real memory, kind of small as a
percentage.

Nothing like using the entire world for your peer review.

You might want to try comp.lang.c.moderated as well.

Norm.

--
md5sum - Unix virus scanner.
http://www.**-**.com/



 Wed, 07 Jan 2004 13:40:15 GMT   
 Strange error with pthreads
I'm making some stabs in the dark here.  Is it possible that the "1" in
the while loop is getting corrupted?  What happens if you replace it
with for(;;) ?  Or if you add in some extraneous code (like x=y+z a few
times, where x, y and z are any old integers) just before the while
loop?  What optimization level are you using for the compile?

--
Stephen Montgomery-Smith
step...@math.missouri.edu
http://www.math.missouri.edu/~stephen



 Wed, 07 Jan 2004 17:24:33 GMT   
 Strange error with pthreads

I followed your last hint of printf log the code but the server didn't
stopped since that day. That's the difficulty of debugging this!

I'm including the makefile here:

CFLAGS = -O2
INCLUDEDIR = -I/usr/local/mysql/include
LIBDIR = -L/usr/local/mysql/lib

# Construct a .o file from a .c file with the same name.
.c.o:
        ${CC} $(CCFLAGS) $(UDEFINES) $(DEFINES) $(INCLUDES) -o $@ -c
$<

interface : interface.o bst.o readabletimeout.o
        gcc $(CFLAGS) -o interface interface.o bst.o
readabletimeout.cpp $(LIBDI
R) -lm -pthread

bst.o : bst.cpp
        gcc -c $(CFLAGS) $(INCLUDEDIR) bst.cpp

interface.o : interface.cpp
        gcc -c $(CFLAGS) $(INCLUDEDIR) interface.cpp

readabletimeout.o : readabletimeout.cpp
        gcc -c $(CFLAGS) $(INCLUDEDIR) readabletimeout.cpp



 Thu, 08 Jan 2004 01:57:48 GMT   
 Strange error with pthreads

Oops. This may create a race condition unless there was locking
around getting and setting the value. Probably not a good idea.

--
md5sum - Unix virus scanner.
http://www.sunperf.com/Security.html



 Thu, 08 Jan 2004 03:22:39 GMT   
 Strange error with pthreads
Pedro Paulo Oliveira jr wrote:

Well it is beginning to confirm my suspicion that maybe you accidently
overwrite the program with data.  Maybe you have a buffer overflow
somewhere or something.  I mean, there is just no way that a while loop
that only contains continues should ever jump out of the loop.  In
adding the debugging code you moved parts of the program around, and so
the buffer overflow or whatever is creating a problem elsewhere or maybe
not at all.  My feeling is that the problem is in the client subroutine.

Also what if you reduce the optimzation level?  Mind you I have almost
identical code which I compiled using -O4 (or maybe -O6 but I don't
think they are different), and it works with no problems.

--
Stephen Montgomery-Smith
step...@math.missouri.edu
http://www.math.missouri.edu/~stephen



 Thu, 08 Jan 2004 05:52:32 GMT   
 Strange error with pthreads

I saw code like this in the book by the person whose name is Richard
Steven's, or something like that.  I don't think that a race condition
is possible.  Once the routine ClientFunc has been called, the data has
already been copied.  The only way you could get problems is if
pthread_create is being run by two different threads, but since it is
beingrun in the main thread, that can never happen.

--
Stephen Montgomery-Smith
step...@math.missouri.edu
http://www.math.missouri.edu/~stephen



 Thu, 08 Jan 2004 05:55:53 GMT   
 Strange error with pthreads

Guess I should not second guess myself.

I defer the greater wisdom of the late Dr. Stevens.

Norm

--
md5sum - Unix virus scanner.
http://www.sunperf.com/Security.html



 Thu, 08 Jan 2004 08:03:35 GMT   
 Strange error with pthreads

I'm now linking with -g option instead of -02 option but the server
felt in 32 hours and didn't generated a core dump. Also gdb was
useless do find out what's tooking place since this program does a
fork and let it's child to handle the server

int main (int argc, char * argv[]) {
        int i;
        FILE * f;
        if (argc < 2) {
                if (BST_Cria_List ("block.key",0) < 0) {
                        fprintf (stderr,"Arquivo de entrada
inv\xe1lido\n");
                        return -1;
                }
        }
        if (BST_Cria_List (argv[1],0) < 0) {
                fprintf (stderr,"Arquivo de entrada inv\xe1lido\n");
                return -1;
        }
        i = fork ();
        if (i < 0) {
                exit (1);
        }
        if (i) { /* nonzero is parent*/
                chdir (DIRETORIO);
                f = fopen ("interface.sh","wt");
                if (f == NULL) {
                        printf ("Cannot write to interface.sh\n
Exiting...\n");
                        exit(-1);
                }
                fprintf (f,"kill %d\ninterface block.key >
/dev/null",i);
                fclose (f);
                f = fopen ("interface.pid","wt");
                if (f == NULL) {
                        printf ("Cannot write to interface.pid\n
Exiting...\n");
                        exit (-1);
                }
                fprintf (f,"%d",i);
                fclose (f);
                exit (0);
        }
        // child becomes the server
        StartSERV ("2398");

- Show quoted text -



 Sun, 11 Jan 2004 02:42:00 GMT   
 
   [ 13 post ] 

Similar Threads

1. Strange error with pthreads

2. Strange SMP (pthreads) scalability problem

3. Strange pthreads problem on Solaris

4. strange pthreads behaviour

5. Strange Strange SPARQ error

6. Strange error message, very strange ...

7. Errors compiling with ftok(), struct timespec, and pthreads

8. bad pthreads (or some other error)?

9. pthreads compilation/linking error for glibc /w linuxthreads


 
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software