This is the mail archive of the
pthreads-win32@sourceware.cygnus.com
mailing list for the pthreas-win32 project.
Re: Bug report with source code attached
- To: Dave Baggett <dmb at itasoftware dot com>, pthreads-win32 at sourceware dot cygnus dot com
- Subject: Re: Bug report with source code attached
- From: reentrant <reentrant at yahoo dot com>
- Date: Thu, 2 Mar 2000 00:32:06 -0800 (PST)
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