On Sun, 20 Feb 2022, LIU Hao wrote: > 在 2022-02-17 03:40, Jeremy Drake via Mingw-w64-public 写道: > > > > Is this assertion failure a sign of a bug in winpthreads, or a sign of a > > bug in glib (such as releasing a lock that is not held, for instance)? > > > > > > Releasing a lock that the calling thread does not own results in undefined > behavior [1]. Returning `EPERM` here is recommended, but not required. I > haven't looked into the source, though. It may be a winpthreads bug or a glib > bug, or both.
This has just shown up again on ARM64 building gtk3. To my knowedge it has not shown up on i686 or x86_64. That makes me kind of suspicious it might be something particular to ARM64, like memory ordering or something. "C:\msys64\clangarm64\bin/glib-compile-resources.EXE" "../gtk/examples/application4/exampleapp.gresource.xml" "--sourcedir" "../gtk/examples/application4/." "--sourcedir" "../gtk/examples/application4" "--internal" "--generate" "--target" "examples/application4/exampleapp4 resources.c" "--dependency-file" "examples/application4/exampleapp4 resources.c.d" Assertion failed: ((((rwlock_t *)*rwl)->valid == LIFE_RWLOCK) && (((rwlock_t *)*rwl)->busy > 0)), file ../mingw-w64/mingw-w64-libraries/winpthreads/src/rwlock.c, line 40 _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
