f



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 screwing up memory badly.

Matt
0
matt13 (6)
2/6/2004 12:25:05 PM
comp.lang.c++ 49423 articles. 6 followers. Post Follow

7 Replies
775 Views

Similar Articles

[PageSpeed] 47

I suggest you post it to SUN forum. many expert are in there
http://forum.sun.com/forum.jsp?forum=5
"Matthew" <matt@holly.com.au> ???
news:16800e49.0402060425.35a4bf22@posting.google.com ???...
> 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 screwing up memory badly.
>
> Matt


0
jj6066 (18)
2/5/2004 4:49:10 AM
You totally misunderstand me. this post is for particular compiler issue.
all of members in SUN forum  use SUN C/C++ compiler. It is easy to get
answer,isn't. I just suggest another solution. I have no means to look down
on this group.
"Sharad Kala" <no.spam_sharadk_ind@yahoo.com> �b�l��
news:c003bn$rvkru$1@ID-221354.news.uni-berlin.de �����g...
>
> "james" <jj6066@dcs.warwick.ac.uk> wrote in message
> news:c002b7$r02$1@mail.dcs.warwick.ac.uk...
> > I suggest you post it to SUN forum. many expert are in there
>
> Hey people on this ng are particularly more intolerant about top-posting.
> Please take care of it :-)
>
>


0
jj6066 (18)
2/5/2004 5:47:54 AM
"james" <jj6066@dcs.warwick.ac.uk> wrote in message
news:c002b7$r02$1@mail.dcs.warwick.ac.uk...
> I suggest you post it to SUN forum. many expert are in there

Hey people on this ng are particularly more intolerant about top-posting.
Please take care of it :-)


0
2/6/2004 1:08:39 PM
"james" <jj6066@dcs.warwick.ac.uk> wrote in message
news:c005pc$3hv$1@mail.dcs.warwick.ac.uk...
> You totally misunderstand me. this post is for particular compiler issue.
> all of members in SUN forum  use SUN C/C++ compiler. It is easy to get
> answer,isn't. I just suggest another solution. I have no means to look down
> on this group.

Actually it's the other way round. You totally misunderstood me.
It is against netiquettes to top post. Posters on this ng point follow it
strictly and expect others also to follow it.
Since in all your posts you were top posting, so I thought that may be I should
point this out to you this in a friendly way.
I hope this clears it up.

Best wishes,
Sharad


0
2/6/2004 2:20:20 PM

Matthew wrote:

> 
> 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.
> 

So what size stack are you using? Do you really need a 16K+ char buffer 
on the stack?

Usually spurious purify reports are dependent on the level of compiler 
optimization you turn on. Some optimizations at the machine code level 
are just plain screwy, for example data prefetched which the code never 
uses because of guards:

   if (x == 0) y = a[x];

and the optimized code may prefetches a[x].

Anyway what do Rational support say? Mail them your program and log file.

0
lilburne (87)
2/6/2004 2:23:49 PM
"james" <jj6066@dcs.warwick.ac.uk> wrote in message
news:c005pc$3hv$1@mail.dcs.warwick.ac.uk...
> You totally misunderstand me. this post is for particular compiler issue.
> all of members in SUN forum  use SUN C/C++ compiler. It is easy to get
> answer,isn't. I just suggest another solution. I have no means to look
down
> on this group.


It looks likes YOU have totally misunderstood Sharad. He was just pointing
out that you were top-posting - a practice that is frowned upon by most
people on this newsgroup.  You may like to read what the FAQ has to say
about top-posting:

http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.4


Regards,
Sumit.


0
sumitrajan (90)
2/6/2004 2:25:21 PM
"james" <jj6066@dcs.warwick.ac.uk> wrote in message
news:c005pc$3hv$1@mail.dcs.warwick.ac.uk...
> "Sharad Kala" <no.spam_sharadk_ind@yahoo.com> �b�l��
> news:c003bn$rvkru$1@ID-221354.news.uni-berlin.de �����g...
> >
> > "james" <jj6066@dcs.warwick.ac.uk> wrote in message
> > news:c002b7$r02$1@mail.dcs.warwick.ac.uk...
> > > I suggest you post it to SUN forum. many expert are in there
> >
> > Hey people on this ng are particularly more intolerant about
top-posting.
> > Please take care of it :-)
[Moved response from sill top-post]
> You totally misunderstand me. this post is for particular compiler issue.
> all of members in SUN forum  use SUN C/C++ compiler. It is easy to get
> answer,isn't. I just suggest another solution. I have no means to look
down
> on this group.

Do you know what "top-posting" is?  It's when you post your response at the
top of the reply instead of the bottom.  Not only does it make discussions
read backwards; when someone is used to reading bottom-posted replies, your
response can be very hard to find.  Since no one top-posts on this
newsgroup, I scrolled through your original reply and could not find a
response - I thought you had accidentally pressed reply or were just being
clueless.

--
KCS


0
2/6/2004 2:47:04 PM
Reply: