[thread][1.34] Assertion in tss_hooks.cpp
Does anyone have any idea why the following assertion: Assertion failed: attached_thread_count == 0, file ..\libs\thread\src\tss_hooks.cpp, line 157 should occur in one of the regex regression tests. It's unique to msvc-6, has only recently started occurring, and I can't reproduce it locally either, the regression log is here: http://tinyurl.com/yhgmam Many thanks, John.
John Maddock wrote:
Does anyone have any idea why the following assertion:
Assertion failed: attached_thread_count == 0, file ..\libs\thread\src\tss_hooks.cpp, line 157
should occur in one of the regex regression tests.
It's unique to msvc-6, has only recently started occurring, and I can't reproduce it locally either, the regression log is here: http://tinyurl.com/yhgmam
I am trying to look into it. Basically it means, that the tests are linked to the threading lib, and a (second) thread is still running when the process is being shut down. But I can't tell at the moment what is starting this additional thread(s). Roland
Roland Schwarz wrote:
.. and I can't reproduce it locally either, the regression log is here: http://tinyurl.com/yhgmam
I am trying to look into it.
It seems I am able to reproduce it. However I get a dialogbox before, telling me about some bad memory reference. Only after pressing ok I see something similar than you described. Do you also need to confirm a message box before? Roland
Roland Schwarz wrote:
Roland Schwarz wrote:
.. and I can't reproduce it locally either, the regression log is here: http://tinyurl.com/yhgmam
I am trying to look into it.
It seems I am able to reproduce it. However I get a dialogbox before, telling me about some bad memory reference. Only after pressing ok I see something similar than you described. Do you also need to confirm a message box before?
No it just runs to completion fine for me: if there is a message box coming up and you manually kill one of threads that would explain the assert I guess. What's the content of the message box? Can you attach a debugger at that point? Many thanks, John.
John Maddock wrote:
No it just runs to completion fine for me:
Hmm, could it be that your regression script is shielding you from the box? I am running it from the command line.
if there is a message box coming up and you manually kill one of threads that would explain the assert I guess. What's the content of the message box? Can you attach a debugger at that point?
I am already running in the debugger. And I located the place where it bombs out. Do you have access to IRC? We can get faster turn around since my email is slow (using fetchmail poll about 10 min). I am online as speedsnail. I do not know enough about regex lib, perhaps you can see at a glance what is happening? However the last line before it goes into CRT DLL is: in test.hpp Line 61. Roland
Roland Schwarz wrote:
John Maddock wrote:
No it just runs to completion fine for me:
Hmm, could it be that your regression script is shielding you from the box? I am running it from the command line.
No I'm running from the command line.
if there is a message box coming up and you manually kill one of threads that would explain the assert I guess. What's the content of the message box? Can you attach a debugger at that point?
I am already running in the debugger. And I located the place where it bombs out. Do you have access to IRC? We can get faster turn around since my email is slow (using fetchmail poll about 10 min). I am online as speedsnail.
I do not know enough about regex lib, perhaps you can see at a glance what is happening?
However the last line before it goes into CRT DLL is: in test.hpp Line 61.
Weird, all it does is call typeid, could that be the issue? John.
John Maddock wrote:
Weird, all it does is call typeid, could that be the issue?
I am afraid it indeed might be the culprit. At least it always faults on type_info::name(void) but with different strange errors, such as Free Heap block at .... modified at ... after it was freed First chance exception in regex_regress_threaded.exe (MSVCRTD.DLL): 0xC0000005: Access Violation Unfortunately the guys from MS forgot to supply the relevant library source for these calls, so I can only guess. Could it be, that typeid(...) or .name() are not thread safe on msvc-6.5 altough they are located in the thread safe version of the runtime lib? Do you have an idea what could be tried to prove or disprove this hypothesis? Roland
Roland Schwarz wrote:
Could it be, that typeid(...) or .name() are not thread safe on msvc-6.5 altough they are located in the thread safe version of the runtime lib?
I found the following: http://groups.google.at/group/microsoft.public.vc.language/browse_frm/thread/81acb64992ed103/153b11ca2b57ee95?lnk=st&q=typeid++not+thread+safe&rnum=2&hl=de#153b11ca2b57ee95 (Search google groups: typeid not thread safe) Unfortunately the guy does not mention how he found out :-( Roland
Roland Schwarz wrote: http://groups.google.at/group/microsoft.public.vc.language/browse_frm/thread/81acb64992ed103/153b11ca2b57ee95?lnk=st&q=typeid++not+thread+safe&rnum=2&hl=de#153b11ca2b57ee95
(Search google groups: typeid not thread safe)
Unfortunately the guy does not mention how he found out :-(
Can you try replacing the call to typeid().name() with just a string literal "" and see if the problem still persists? Many thanks for your help with this ! John.
John Maddock wrote:
Can you try replacing the call to typeid().name() with just a string literal "" and see if the problem still persists?
Did this. Problem gone. It looks like typeid(...).name() is the culprit :-( What now? btw.: There are lot of C4786 warnings for msvc-6.5. This is well known, and usually cured by disabling this warning. Roland
Roland Schwarz wrote:
John Maddock wrote:
Can you try replacing the call to typeid().name() with just a string literal "" and see if the problem still persists?
Did this. Problem gone. It looks like typeid(...).name() is the culprit :-(
What now?
OK I'll patch the source: typid is only used to give meaningful messages when a failure occures, I'll disable it for this specific circumstance.
btw.: There are lot of C4786 warnings for msvc-6.5. This is well known, and usually cured by disabling this warning.
Yeh, except quite a few std headers turn it back on again! I've tried pretty hard to disable these in the past, but have pretty much given up now, especially given how old and broken this compiler is :-( If you think you can see an easy way to fix these please do go ahead, but I honestly wouldn't spend any time on unless you're really keen ! :-) Many thanks for tracking this one down! John.
Roland, Sorry to bother you again, but could you see if the current cvs source has fixed this issue: it should have, but I'm still seeing the issue flagged up in the regression reports. Many thanks, John.
John Maddock ha escrito:
Roland,
Sorry to bother you again, but could you see if the current cvs source has fixed this issue: it should have, but I'm still seeing the issue flagged up in the regression reports.
The offending reports are outdated (14 Dec and 11 Dec), the cells should turn green by their next cycle. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (3)
-
Joaquín Mª López Muñoz -
John Maddock -
Roland Schwarz