By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,660 Members | 1,953 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,660 IT Pros & Developers. It's quick & easy.

Purify problem or compiler problem?

P: n/a
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
Nov 14 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Matthew <ma**@holly.com.au> spoke thus:
I am using sun's CC (c++ compiler) to compile the follow code:
#include <pthread.h>
This is purify's output: Is it the compiler/linker bug or it purify making things up?


(All this suggests that you'd be better served in a more topical
newsgroup.)

Your post is off-topic for comp.lang.c. Please visit

http://www.csclub.uwaterloo.ca/u/dj3...lc-welcome.txt
http://www.eskimo.com/~scs/C-faq/top.html
http://benpfaff.org/writings/clc/off-topic.html

for posting guidelines and frequently asked questions. Thank you.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #2

P: n/a
Matthew wrote:
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

man pthread_attr_setstackaddr

/J
Nov 14 '05 #3

P: n/a
Johan Lindh wrote:
Matthew wrote:
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


man pthread_attr_setstackaddr

/J


Uh, I meant

man pthread_attr_setstacksize

...(of course :P)

Nov 14 '05 #4

P: n/a
Johan Lindh wrote:

Johan Lindh wrote:

man pthread_attr_setstackaddr

/J


Uh, I meant

man pthread_attr_setstacksize


Do you know any newsgroups where threads are on topic ?

--
pete
Nov 14 '05 #5

P: n/a
pete wrote:
Johan Lindh wrote:
Johan Lindh wrote:


man pthread_attr_setstackaddr

/J


Uh, I meant

man pthread_attr_setstacksize

Do you know any newsgroups where threads are on topic ?


Sure!
alt.sex.spam

Nov 14 '05 #6

P: n/a
Johan Lindh wrote:

pete wrote:
Johan Lindh wrote:
Johan Lindh wrote:


man pthread_attr_setstackaddr

/J

Uh, I meant

man pthread_attr_setstacksize

Do you know any newsgroups where threads are on topic ?


Sure!
alt.sex.spam


Then take your discussion to there.

--
pete
Nov 14 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.