thanks, I was going to ask you the same thing , I’m using printf() thoughout
my threads and I in the Watcom 10.6 manual printf() is said to be thread
safe. Anyway just to see I’ve removed all the calls to printf() and it
didn’t help ( I was hoping it would). I’m thinking maybe not being able to
create threads has something to do with the shared memory. I open it with
shm_open, then I map to it (mmap()) three times in three different places
but I don’t use ltrunc(). My driver writes to the shared memory locations
and the PCI card reads the memory and mirrows it to the communication memory
on the card.
I’m also suspecting stack corruption but don’t know how to prove it.
“Mario Charest” <mcharest@nozinformatic.com> wrote in message
news:3adddee5.20388617@inn.qnx.com…
On Wed, 18 Apr 2001 09:57:19 -0400, “Mariola Solodko”
mariola.m.solodko@ca.abb.com> > wrote:
Common mistake with thread is to use printf in each thread. In my
experience that can cause problem because file descriptor are
not thread safe.
thanks Rennie, I was using Kevin’s computer to post these messages but
I’m
not Kevin, he seems to know you though.
I am still at the same point, I don’t think I have a heap corruption, I
was
running some utilities to check the heap and it looked ok, I’ve checked
every single calloc(), memset(), memcpy() and strcpy(). The code I’m
working with is a working code for a different operating system and the
additions I’ve made were to make it compatible with QNX. It’s a PCI
driver, uses a interrupt handler, semaphores and shared memory. The
program
works fine if I create all the threads at the start up.
I’ve checked my resources when running the program and I’m not exceeding
any.
I ran out of ideas, I will have make additions to this program to support
redundancy and maybe then something will come up.
thanks again
“Rennie Allen” <> RAllen@csical.com> > wrote in message
news:> D4907B331846D31198090050046F80C903C80B@exchangecal.hq.csical.com> …
I am not sure how to find the heap corruption problem if it exists.
I think there is a debugging malloc library for QNX4 (there is one for
QNX6) on the website.
I am
allocating thread stack first, using calloc() then I call
_beginthread
but
I’ve tried it both ways and I get the same results.
Try static allocation of the stack:
eg.
stack[NUM_THREADS][2048];
probably not what you want, but a good diagnostic step.
The other test program
I am trying to run in the background will return an error equal to 11
when
trying to create a thread, which means too many threads.
Yes, but once there is heap (or stack) corruption, it isn’t unlikely to
see meaningless error returns. You could check to make sure you
haven’t
exhausted process entries (maybe you are allocating a lot of proxies
?).
I am working with
a huge program and trying to go through every single memcpy and
strcpy
is
impossible but I might have to do that. Any suggestions?
Look for callocs/mallocs/memcpy/strcpy assignments where
sizeof() is being user rather than sizeof(*variable). If it
is
a huge program there is a chance that a variable pointer was wrongly
declared as some type of structure, and (at the same time as the first
mistake) the calloc for the pointer was done as a sizeof(). When the programmer later tried to access a member that
wasn’t part of the wrongly assigned type they couldn’t compile, and
noticed their error, however when they fixed it they didn’t update the
calloc type. If the sizeof() the correct type is bigger than the
sizeof() the initial (wrong) type, then heap corruption will occur (the
same logic applies to memcpy’s but in reverse - i.e. if the correct
type
is smaller than the wrong type, then heap corruption occurs).
Hope this helps Kevin
\
