public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <20000302083206.17320.qmail@web1404.mail.yahoo.com> (raw)

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

             reply	other threads:[~2000-03-02  0:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-02  0:32 reentrant [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-03-02  7:46 Bossom, John
2000-03-02 16:15 ` Dave Baggett
2000-03-01  7:38 Bossom, John
2000-03-01  9:54 ` Dave Baggett
2000-02-29 23:59 Dave Baggett
2000-03-01  1:10 ` Dave Baggett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20000302083206.17320.qmail@web1404.mail.yahoo.com \
    --to=reentrant@yahoo.com \
    --cc=dmb@itasoftware.com \
    --cc=pthreads-win32@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).