Using the latest Wine release, I see this error repeated over and over:
err:ntdll:RtlpWaitForCriticalSection section 0x70460350 "?" wait timed out, retrying (60 sec) tid=08436988
when clicking on the CML demo at Adobes SVG demo site. Google indicates that this error can be caused by all sorts of things, one guy said it was due to Wine being a lot slower than Windows.
So, could anybody write an explanation of what this error means?
thanks -mike
Mike Hearn wrote:
Using the latest Wine release, I see this error repeated over and over:
err:ntdll:RtlpWaitForCriticalSection section 0x70460350 "?" wait timed out, retrying (60 sec) tid=08436988
when clicking on the CML demo at Adobes SVG demo site. Google indicates that this error can be caused by all sorts of things, one guy said it was due to Wine being a lot slower than Windows.
So, could anybody write an explanation of what this error means?
This error means that a thread tries to acquire a critical section lock that is never released.
Some critical section are initialized either staticaly with CRITICAL_SECTION_INIT wich set a name to the lock or dynamicaly with InitializeCriticalSection which set the name to NULL (printed as ? wich doesn't help :-( ).
I think, It would be cool to have all locks named and thus make debugging and bug report easier. It's not a hard task but names must be meaningfull. :-)
Christian.
On Wed, 22 Jan 2003, Christian Costa wrote: [...]
err:ntdll:RtlpWaitForCriticalSection section 0x70460350 "?" wait timed out, retrying (60 sec) tid=08436988
[...]
I think, It would be cool to have all locks named and thus make debugging and bug report easier. It's not a hard task but names must be meaningfull. :-)
I guess you mean all Wine locks should be named (I'm not sure it would be good to give a name to unnamed application locks).
Naming the Wine locks would be nice (or is it done already?). But more than meaningful names, what we would need are grep-able names :-)
Francois Gouget wrote:
On Wed, 22 Jan 2003, Christian Costa wrote: [...]
err:ntdll:RtlpWaitForCriticalSection section 0x70460350 "?" wait timed out, retrying (60 sec) tid=08436988
[...]
I think, It would be cool to have all locks named and thus make debugging and bug report easier. It's not a hard task but names must be meaningfull. :-)
I guess you mean all Wine locks should be named
Yes! :-)
(I'm not sure it would be good to give a name to unnamed application locks).
Of course not.
Naming the Wine locks would be nice (or is it done already?).
No, it isn't.
But more than meaningful names, what we would need are grep-able names :-)
What do you mean with grep-able ?
Christian
Christian Costa wrote:
I think, It would be cool to have all locks named and thus make debugging and bug report easier. It's not a hard task but names must be meaningfull. :-)
I guess you mean all Wine locks should be named
Yes! :-)
... Naming the Wine locks would be nice (or is it done already?).
No, it isn't.
All the static CRITICAL_SECTIONs in Wine DLLs have names. The only unnamed ones are those that are initialized at runtime. To give these a name, we'd either have to convert them to static initialization, or change InitializeCriticalSection to somehow generate a name from the caller's program counter.
But more than meaningful names, what we would need are grep-able names :-)
What do you mean with grep-able ?
Ones that are easy to search for, e.g. that contain the source filename. - Dan
Dan Kegel wrote:
Christian Costa wrote:
I think, It would be cool to have all locks named and thus make debugging and bug report easier. It's not a hard task but names must be meaningfull. :-)
I guess you mean all Wine locks should be named
Yes! :-)
... Naming the Wine locks would be nice (or is it done already?).
No, it isn't.
All the static CRITICAL_SECTIONs in Wine DLLs have names. The only unnamed ones are those that are initialized at runtime.
It is what I said! No? :-)
To give these a name, we'd either have to convert them to static initialization, or change InitializeCriticalSection to somehow generate a name from the caller's program counter.
What about writing a new macro that initializes the name in the CRITICAL_SECTION struct. So in the code, we can do :
................. InitializeCriticalSection(&crit); SET_CRITICAL_SECTION_NAME(&crit,"name"); ..................
But more than meaningful names, what we would need are grep-able names :-)
What do you mean with grep-able ?
Ones that are easy to search for, e.g. that contain the source filename.
The filename could be added to the name with the macro I mentionned above. CRITICAL_SECTION_INIT does that (__FILE__ ": " name).
Christian.
Christian Costa wrote:
All the static CRITICAL_SECTIONs in Wine DLLs have names. The only unnamed ones are those that are initialized at runtime.
It is what I said! No? :-)
I guess I missed part of what you said, sorry.
To give these a name, we'd either have to convert them to static initialization, or change InitializeCriticalSection to somehow generate a name from the caller's program counter.
What about writing a new macro that initializes the name in the CRITICAL_SECTION struct. ................. InitializeCriticalSection(&crit); SET_CRITICAL_SECTION_NAME(&crit,"name");
Hmm. Seems to be the Wine DLL sources should try to avoid stuff that doesn't compile under Windows. That said, we could provide a header file that defined SET_CRITICAL_SECTION_NAME in Windows, and made it do nothing.
Furthermore, we could be real sneaky, and make that header file turn InitializeCriticalSection into a macro that called the real InitializeCriticalSection, then called SET_CRITICAL_SECTION_NAME, so no source changes would be needed to get the name in there, maybe. - Dan
Dan Kegel wrote:
Christian Costa wrote:
All the static CRITICAL_SECTIONs in Wine DLLs have names. The only unnamed ones are those that are initialized at runtime.
It is what I said! No? :-)
I guess I missed part of what you said, sorry.
To give these a name, we'd either have to convert them to static initialization, or change InitializeCriticalSection to somehow generate a name from the caller's program counter.
What about writing a new macro that initializes the name in the CRITICAL_SECTION struct. ................. InitializeCriticalSection(&crit); SET_CRITICAL_SECTION_NAME(&crit,"name");
Hmm. Seems to be the Wine DLL sources should try to avoid stuff that doesn't compile under Windows. That said, we could provide a header file that defined SET_CRITICAL_SECTION_NAME in Windows, and made it do nothing.
If CRITICAL_SECTION_INIT compiles why not SET_CRITICAL_SECTION_NAME ?
Furthermore, we could be real sneaky, and make that header file turn InitializeCriticalSection into a macro that called the real InitializeCriticalSection, then called SET_CRITICAL_SECTION_NAME, so no source changes would be needed to get the name in there, maybe.
In that case our InitializeCriticalSection macro would have one more parameter (the name) than the real function. I personaly think this will confused people more than an optional (but preferable for debugging) macro.
Christian.
Christian Costa wrote:
Hmm. Seems to be the Wine DLL sources should try to avoid stuff that doesn't compile under Windows. That said, we could provide a header file that defined SET_CRITICAL_SECTION_NAME in Windows, and made it do nothing.
If CRITICAL_SECTION_INIT compiles why not SET_CRITICAL_SECTION_NAME ?
It doesn't compile under MSVC, I bet. But I haven't tried it, perhaps it does.
Furthermore, we could be real sneaky, and make that header file turn InitializeCriticalSection into a macro that called the real InitializeCriticalSection, then called SET_CRITICAL_SECTION_NAME, so no source changes would be needed to get the name in there, maybe.
In that case our InitializeCriticalSection macro would have one more parameter (the name) than the real function.
Nope. It wouldn't. We would construct the name from __FILE__ and __LINE__. - Dan
Dan Kegel wrote:
Christian Costa wrote:
Hmm. Seems to be the Wine DLL sources should try to avoid stuff that doesn't compile under Windows. That said, we could provide a header file that defined SET_CRITICAL_SECTION_NAME in Windows, and made it do nothing.
If CRITICAL_SECTION_INIT compiles why not SET_CRITICAL_SECTION_NAME ?
It doesn't compile under MSVC, I bet. But I haven't tried it, perhaps it does.
Furthermore, we could be real sneaky, and make that header file turn InitializeCriticalSection into a macro that called the real InitializeCriticalSection, then called SET_CRITICAL_SECTION_NAME, so no source changes would be needed to get the name in there, maybe.
In that case our InitializeCriticalSection macro would have one more parameter (the name) than the real function.
Nope. It wouldn't. We would construct the name from __FILE__ and __LINE__.
- Dan
So you suggest to not set a name ? What happened if there are two or more critical sections in the same source file, a file that has changed. Having no name make things harder to distinguish them in a log. OK, it is a little paranoid. :-)
Christian
Christian Costa wrote:
In that case our InitializeCriticalSection macro would have one more parameter (the name) than the real function.
Nope. It wouldn't. We would construct the name from __FILE__ and __LINE__.
So you suggest to not set a name ? What happened if there are two or more critical sections in the same source file, a file that has changed. Having no name make things harder to distinguish them in a log. OK, it is a little paranoid. :-)
It would have the filename and line number as the name... that would be enough to let you distinguish between locks. And it even lets you know if you have the right sources, 'cause otherwise the line number won't match :-)
The chief advantage, though, is that it gets us automatically generated names with no source changes, at least for static calls. (Won't help with ones done via GetProcAddr, but that's ok.) - Dan
Dan Kegel wrote:
Christian Costa wrote:
In that case our InitializeCriticalSection macro would have one more parameter (the name) than the real function.
Nope. It wouldn't. We would construct the name from __FILE__ and __LINE__.
So you suggest to not set a name ? What happened if there are two or more critical sections in the same source file, a file that has changed. Having no name make things harder to distinguish them in a log. OK, it is a little paranoid. :-)
It would have the filename and line number as the name... that would be enough to let you distinguish between locks. And it even lets you know if you have the right sources, 'cause otherwise the line number won't match :-)
The chief advantage, though, is that it gets us automatically generated names with no source changes, at least for static calls. (Won't help with ones done via GetProcAddr, but that's ok.)
Is there any calls done via GetProcAddr in wine sources ? I guess not.
In this case, CRITICAL_SECTION_INIT should be update, at least to have the line number. :-)
So, if everyone agree. That 's fine for me. :-) Would you submit a patch that handle that ?
- Dan
Christian Costa wrote:
In that case our InitializeCriticalSection macro would have one more parameter (the name) than the real function.
Nope. It wouldn't. We would construct the name from __FILE__ and __LINE__.
It would have the filename and line number as the name... that would be enough to let you distinguish between locks. ... The chief advantage, though, is that it gets us automatically generated names with no source changes, at least for static calls...
In this case, CRITICAL_SECTION_INIT should be update, at least to have the line number. :-)
So, if everyone agree. That 's fine for me. :-) Would you submit a patch that handle that ?
I will give it a try. Then people can pass judgement on whether it's a good idea. - Dan
Christian Costa titan.costa@wanadoo.fr writes:
In this case, CRITICAL_SECTION_INIT should be update, at least to have the line number. :-)
So, if everyone agree. That 's fine for me. :-) Would you submit a patch that handle that ?
As discussed recently, CRITICAL_SECTION_INIT should be removed since it's not in the standard headers. So you probably don't want to start changing it now...
Alexandre Julliard wrote:
Christian Costa titan.costa@wanadoo.fr writes:
In this case, CRITICAL_SECTION_INIT should be update, at least to have the line number. :-)
So, if everyone agree. That 's fine for me. :-) Would you submit a patch that handle that ?
As discussed recently, CRITICAL_SECTION_INIT should be removed since it's not in the standard headers. So you probably don't want to start changing it now...
OK, maybe I'll make this patch remove CRITICAL_SECTION_INIT, too. Thanks! - Dan
-
Alexandre Julliard -
Christian Costa -
Dan Kegel -
Francois Gouget -
Mike Hearn