After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 660096 - glib/rwlock tests failure (tests asserted)
glib/rwlock tests failure (tests asserted)
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gthread
unspecified
Other Windows
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-09-26 05:00 UTC by Fan, Chun-wei
Modified: 2011-09-26 12:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
winxp threads: detect SRWLock emulation reentrancy (3.47 KB, patch)
2011-09-26 08:48 UTC, Allison Karlitskaya (desrt)
committed Details | Review

Description Fan, Chun-wei 2011-09-26 05:00:30 UTC
Hi,

When running the rwlock tests on Windows XP, tests #3 and #6 failed as they 
asserted, with the following output:

(debug) GThread using Windows XP mode
<snip>
/thread/rwlock3: **
ERROR:..\..\..\glib\tests\rwlock.c:59:???: assertion failed: (!ret)
<snip, taken from another run with test #3 commented out>
/thread/rwlock6: **
ERROR:..\..\..\glib\tests\rwlock.c:103:???: assertion failed: (!ret)

By the way, theses tests ran fine on Windows 7, where the workaround code for 
RWLock etc is not required.

Thank you, and God bless!
Comment 1 Allison Karlitskaya (desrt) 2011-09-26 08:26:12 UTC
Tricky.

This is caused by the fact that CRITICAL_SECTION (on which the Windows XP reader-writer lock emulation is based) is recursive, and the testcase works by acquiring the lock, then testing that it is unable to acquire it again:

  ret = g_rw_lock_writer_trylock (&lock);
  g_assert (ret);
  ret = g_rw_lock_writer_trylock (&lock);
  g_assert (!ret);

I may have to add a double-check to circumvent the recursive nature of CRITICAL_SECTION.
Comment 2 Allison Karlitskaya (desrt) 2011-09-26 08:48:57 UTC
Created attachment 197451 [details] [review]
winxp threads: detect SRWLock emulation reentrancy

We lack SRWLock on Windows XP, so we use CRITICAL_SECTION to emulate it
there.  SRWLock is non-recursive, but CRITICAL_SECTION will happily
allow itself to be acquired multiple times by the same thread.

We need to detect if our second acquire succeeded because of the
recursive nature of CRITICAL_SECTION.  In the case of a _lock()
operation, we would normally have deadlocked, so abort.  In the case of
a _trylock() operation, we need to ensure that FALSE is properly
returned.

Problem caught by Matthias Clasen and Chun-wei Fan.
Comment 3 Fan, Chun-wei 2011-09-26 10:17:22 UTC
Hi Ryan,

Your patch worked fine on XP-I will test again on Win7/x64 a bit later.

However, another issue that popped up on XP is that the gwakeup.c test under 
gthread would -sometimes- get caught in an infinite loop when it does the 
/gwakeup/threaded test.  Please let me know if more info is needed here-sorry,
couldn't collect that now because I need to head out soon.  Again, this did not
occur on Windows7.

Thank you, and God bless!
Comment 4 Fan, Chun-wei 2011-09-26 10:19:14 UTC
Hi Ryan,

It seems that problem in comment #3 existed before your patch, so it shouldn't
have been introduced by your patch.

Thank you, and God bless!
Comment 5 Allison Karlitskaya (desrt) 2011-09-26 12:56:05 UTC
Thanks for the review.

Attachment 197451 [details] pushed as fdc594e - winxp threads: detect SRWLock emulation reentrancy