Program exit

Bjarne Orn Hansen — Fri, 12 Oct 2001 19:37:17 -0000

When a thread uses global semaphores, mutex or
condition varibles and is not finished, and not
detached when the main program exits. It segfaults
or hangs the main program.

Thread collition

Anonymous — Sun, 07 Oct 2001 13:20:29 -0000

Two simultaneous threads will collide, if run
extensively and using the standard template library.

Buffer overflow risk

Wolfgang Wieser — Wed, 18 Jul 2001 17:28:18 -0000

Hi guys,

while looking at the threads source code in order to
decide whether to use it for a project on a GPL'ed
network server a bug popped to my eyes:

-------<shared.C>---------
void shared_mem::change_proj(const char *p_root)
{
strncpy( _key_root,p_root,79 );
}
---------------------------
...is unsafe because the strncpy() copies just the
first 79 bytes leavind the dest string unterminated
in case the source is longer.
In combination with...
---------<shared.C>-----------
int shared_mem::create_proj(const char *p_id)
{
int fd;
> string s = _key_root;
sto_iterator i;
-----------------------------
...this is unsafe as the string assignment relies
on proper termination.

BTW, I really don't understand why you're using a
damn 80 char limit on _key_root. If you really have
to use a limit, then I would appreciate a
#define or const int for the limit.
Maybe you should also check the calls to strcpy()
in mutex.C, cond.C, semaphore.C:
Why not use something like
------<snip>-------
void semaphore::project_part(const char *p_part)
{
if(s_project) delete[] s_project;
size_t len = p_part ? strlen(p_part) : 0;
s_project = new char[len+1];
*s_project='\0';
if(p_part) strcpy(s_project,p_part);
}
----------------
(assuming that the s_project pointer may change and
the function is not critical to runtime efficiancy.)

Regards,
W. Wieser

Please drop me an e-mail to
wwieser@users.sourceforge.net when you have read
this as I don't know if you're using the bug tracking
system.

Recent changes to bugs

Program exit

Thread collition

Buffer overflow risk