Professional Web Applications Themes

Purify problem or compiler problem? - UNIX Programming

Hi, I am using sun's CC (c++ compiler) to compile the follow code: #define __REENTRANT #include <stdio.h> #include <pthread.h> void *one(void *dummy); void two(void); void output(void); int main (int argc, char **argv) { pthread_t tid; pthread_create( &tid, NULL, one, NULL ); pthread_join(tid,NULL); } void *one(void *dummy) { output(); two(); return NULL; } void two(void) { output(); } void output(void) { //char string[16468]; //This one purify likes //char string[16469]={0}; //This and greater makes purify spit BSW's char string[16469]; //This and greater makes purify spit a IPW/R's string[0]='

Thread: Purify problem or compiler problem?

'; } This is purify's output: IPW: Invalid pointer write This is occurring while in ...

  1. #1

    Default Purify problem or compiler problem?

    Hi,

    I am using sun's CC (c++ compiler) to compile the follow code:

    #define __REENTRANT
    #include <stdio.h>
    #include <pthread.h>

    void *one(void *dummy);

    void two(void);
    void output(void);

    int main (int argc, char **argv)
    {
    pthread_t tid;
    pthread_create( &tid, NULL, one, NULL );
    pthread_join(tid,NULL);
    }

    void *one(void *dummy)
    {
    output();
    two();
    return NULL;
    }

    void two(void)
    {
    output();
    }

    void output(void)
    {
    //char string[16468]; //This one purify likes
    //char string[16469]={0}; //This and greater makes purify spit
    BSW's
    char string[16469]; //This and greater makes purify spit a
    IPW/R's
    string[0]='\0';
    }

    This is purify's output:

    IPW: Invalid pointer write
    This is occurring while in thread 7:
    void output() [testmain3.o]
    void two() [testmain3.o]
    void*one(void*) [testmain3.o]
    _thread_start [libthread.so.1]
    Writing 1 byte to 0x7e5fbbef on the stack of thread 7.
    Address 0x7e5fbbef is 16473 bytes below frame pointer in
    function void output().

    Thread Summary : 7 threads in existence
    Thread 0 [main thread]
    Stack Limit : (0xff3f0000 0xffbf0000), size = 0x800000
    Thread 1
    Stack Limit : (0x7ef10000 0x7f010000), size = 0x100000
    Stack Use : (0x7f00fa30 0x7f00fd54), size = 0x324
    Thread 2
    Stack Limit : (0x7e652000 0x7e656000), size = 0x4000
    Stack Use : (0x7e655978 0x7e655d54), size = 0x3dc
    Thread 3
    Stack Limit : (0x7f902b64 0x7f91e3f8), size = 0x1b894
    Stack Use : (0x7f9076d0 0x7f9078f4), size = 0x224
    Thread 4
    Stack Limit : (0x7ee0e000 0x7ef0e000), size = 0x100000
    Stack Use : (0x7ef0db30 0x7ef0dd54), size = 0x224
    Thread 6
    Stack Limit : (0x7e612000 0x7e616000), size = 0x4000
    Stack Use : (0x7e615b28 0x7e615d54), size = 0x22c
    Thread 8
    Stack Limit : (0x7e632000 0x7e634000), size = 0x2000
    Stack Use : (0x7e633b28 0x7e633d54), size = 0x22c

    This is with CC. With gcc or g++ it does not have this problem. cc has
    the problem too but with a larger number in the array.

    Is it the compiler/linker bug or it purify making things up?

    If it is the compiler I assume I am ing up memory badly.

    Matt
    Matthew Guest

  2. #2

    Default Re: Purify problem or compiler problem?

    On 6 Feb 2004 04:32:57 -0800
    com.au (Matthew) wrote:
     
    I think Purify might be correct. (Note that I was on the team that
    ported Purify to Tru64 Unix). I'm not sure why Purify is saying thread
    7, then printing the stats for 0 through 8, but you are exceeding the
    stack size on several threads.
    Also, the stack allocation scheme for threads differs depending on the
    compiler in use, which is why you get different results with CC and cc.

    --
    Jerry Feldman <gaf-nospam-at-blu.org>
    Boston Linux and Unix user group
    http://www.blu.org PGP key id:C5061EA9
    PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
    Jerry Guest

  3. #3

    Default Re: Purify problem or compiler problem?

    On 6 Feb 2004 04:32:57 -0800
    com.au (Matthew) wrote:
     
    I thought I posted an answer for this.
    The issue here is that your string is too large for the thread's stack,
    and Purify is throwing the proper thing. Each compiler lays out its
    threads differently.

    One possible solution is to use an attribute, (eg.
    pthread_attr_setstacksize) to set the stacksize. Also, I question your
    use of the #define __REENTRANT, but I don't know Sun's use of that.
    Normally, that flag is for the building of the reentrant libc.so.

    I assume that Sun's compiler may also place some per-thread data
    adjacent to the visible stack, but that is just an assumption.

    --
    Jerry Feldman <gaf-nospam-at-blu.org>
    Boston Linux and Unix user group
    http://www.blu.org PGP key id:C5061EA9
    PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
    Jerry Guest

Similar Threads

  1. Compiler Problem
    By wruth in forum Macromedia Flex General Discussion
    Replies: 2
    Last Post: June 28th, 12:57 AM
  2. problem about compiler
    By Pagoda in forum PERL Beginners
    Replies: 3
    Last Post: April 13th, 06:39 PM
  3. Strange compiler problem
    By Scott in forum Mac Programming
    Replies: 3
    Last Post: December 23rd, 04:31 AM
  4. C compiler problem
    By Raghu in forum Sun Solaris
    Replies: 7
    Last Post: July 4th, 06:50 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139