J
james
I suggest you post it to SUN forum. many expert are in there
http://forum.sun.com/forum.jsp?forum=5
http://forum.sun.com/forum.jsp?forum=5
J
james
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.
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.
M
Matthew
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
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
S
Sharad Kala
james said:
Hey people on this ng are particularly more intolerant about top-posting.
Please take care of it
S
Sharad Kala
james said:
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
L
lilburne
Matthew said:
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.
S
Sumit Rajan
james said:
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.
K
Kevin Saff
[Moved response from sill top-post]
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.
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.