From mboxrd@z Thu Jan  1 00:00:00 1970
From: reentrant <reentrant@yahoo.com>
To: Dave Baggett <dmb@itasoftware.com>, pthreads-win32@sourceware.cygnus.com
Subject: Re: Bug report with source code attached
Date: Thu, 02 Mar 2000 00:32:00 -0000
Message-id: <20000302083206.17320.qmail@web1404.mail.yahoo.com>
X-SW-Source: 2000/msg00019.html

For the first case, if you add a pthread_attr_destroy after the last assert?

I haven't looked at the pthread source to verify, but some pthread init
functions allocate memory which must be deallocated by calling the associated
destroy function.

Dave

--- Dave Baggett <dmb@itasoftware.com> wrote:
> I have a sizeable pthreads-based server application that works well under
> Linux and NT (using pthreads-win32). Under NT, however, it crashses
> periodically. After several days of debugging, I have isolated the source of
> the crashes to a small bit of code (included below) which looks to me to be
> perfectly innocent. However, I may not understand pthreads semantics
> adequately  -- it wouldn't be the first time --  so my code might be wrong.
> 
> If I compile the program below and run it with a "-l" argument ("l" as in
> "lose"), I get:
> 
>   The instruction at "0x7800d557" referenced memory at "0x00000170".
>   The memory could not be "written".
> 
> This happens after a delay that varies between 0 and 15 minutes.  The
> instruction address never varies, but the referenced memory location
> does. The debugger shows that it's dying in the malloc call in
> pthread_attr_init. I.e., the heap is somehow getting corrupted.
> 
> If I run it without "-l", it seems to be able to run for hours without
> crashing. Am I correct in assuming that the two modes of operation should
> be equivalent (aside from the fact that I might be leaking memory by
> not freeing the attrs)?
> 
> This happens with the 1999-11-02 snapshot as well as the 1999-09-17
> snapshot.
> 
> I see nothing in the win32-pthreads source that looks like it could cause
> this.
> However, I did notice that pthread_attr_init() returns you an attr that sets
> the stacksize to 1K, which doesn't seem good. Explicitly setting the
> stacksize
> won't fix the crash problem, but it still seems like you ought to default the
> stack to 256K or something reasonable.
> 
> Apologies in advance if I'm just doing something stupid. :)
> 
> Dave Baggett
> dmb@itasoftware.com
>
-------------------------------------------------------------------------------
> //
> // Call with -l argument to cause a crash.
> // Compiled with MSVC6 using these args:
> //   -nologo -D WIN32 -D _WINDOWS -ML -MTd -GX -Od -G6 -W3 -Zi
> //
> #include "pthread.h"
> #include <assert.h>
> 
> void *NOP(void *p) { return NULL; }
> 
> int
> main(int argc, char **argv)
> {
>     bool lose = (argc == 2 && !strcmp(argv[1], "-l"));
>     for (;;) {
>         int retval;
>         pthread_t tid;
> 
>         if (lose) {
>             pthread_attr_t attr;
>             retval = pthread_attr_init(&attr);
>             assert(retval==0);          // success
>             retval = pthread_attr_setdetachstate(&attr,
> PTHREAD_CREATE_DETACHED);
>             assert(retval==0);          // success
>             retval = pthread_create(&tid, &attr, NOP, NULL);
>             assert(retval==0);
>         }
>         else {
>             retval = pthread_create(&tid, NULL, NOP, NULL);
>             assert(retval==0);          // success
>             retval = pthread_detach(tid);
>             assert(retval==0);
>         }
>     }
>     return 0;
> }
> 
> 
> 
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com