Pelles C forum

Pelles C => Bug reports => Topic started by: andi.martin on December 14, 2005, 10:11:23 PM

Title: probably bug with multithread runtime lib
Post by: andi.martin on December 14, 2005, 10:11:23 PM

Hi Pelle,

I currently work on a project, which uses two threads. All worked fine. Till to a few minutes... as I switched to the multithreaded lib (runtime lib in the compiler settings)!
It's quite simple: The first thread calls vprintf and the program flies with "never-comeback-airlines".

I reduced the program to the essential. Now only the 2nd thread is started and the vprintf is done. I think there's propably a bug with the runtime lib.

Are you interested to take a look on that source?

Regards,
Andreas

Title: Re: probably bug whith multithread runtime lib
Post by: andi.martin on December 14, 2005, 11:33:48 PM

I located the problem. I allocated a console for error output. When redirecting STD_OUTPUT, there seems to be access rights for the first thread which uses the handle. The second thread suspends after trying to write to that handle...

Now using WriteFile or. WriteConsole works well.

Title: probably bug with multithread runtime lib
Post by: Pelle on December 15, 2005, 08:49:05 PM

So.... do you still think it's a bug...?

Pelle

Title: probably bug with multithread runtime lib
Post by: andi.martin on December 16, 2005, 10:43:19 AM

I think, that it's not...

I first used

Code: [Select]

  // Redirect "stdout" to the console window.
AllocConsole();
fclose(stdout);
setbuf(stdout, NULL);
*stdout = *_fdopen(_open_osfhandle((long)GetStdHandle(STD_OUTPUT_HANDLE), 0), "w");

for debugging output. That causes conflicts when two threads try to write in it (deadlock).
With three other variants there are no deadlocks:
1) Opening a log file and write via fprintf.
2) Preparing the string via sprinft and output through OutputDebugString.
3) Having a console (AllocConsole) too, but prepare the string via sprintf and write to the console via WriteFile.

The problems seems to be the access right to the console output with a redirected handle for printf (to stdout).
I'm not sure if it's worth the time, since

Code: [Select]

*stdout = *_fdopen(_open_osfhandle(... is a hard workaround, not Ansi C and not possible with all compilers. To me, _fdopen seems to erase the "share write" flag...
If this is good behaviour, I'm not shure...

I sent you some example source to try.


Regards,
Andreas

Title: probably bug with multithread runtime lib
Post by: Pelle on December 16, 2005, 08:53:30 PM

Thanks - I will look at it...

Pelle