2024-11-21 23:57 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000334mercuryBugpublic2014-06-30 15:06
Reporterpbone 
Assigned Topbone 
PriorityhighSeveritymajorReproducibilitysometimes
StatusresolvedResolutionfixed 
Platformx86_64OSDebian LinuxOS Versionjessie or sid
Product Version 
Target VersionFixed in Version 
Summary0000334: Low level C parallel grades crash with libc6 > 2.19.x and newer Intel processors
DescriptionIntel's latest processors include some transactional memory support instructions (TSX). These can be used to implement lock free data structures and can also be used to implement more traditional locking primitives such as mutexes. Specifically new versions of eglibc use this to implement lock elision for pthreads mutexes: http://lwn.net/Articles/534758/ If you have a supported processor eglibc will use this by default.

There has been a dormant bug in Mercury (or possibly Boehm GC) that now shows up since I upgraded to libc6 2.19.1, I use a Intel i7-4770 which has the TSX feature and now some parallel Mercury programs crash. A GP fault is thrown by some code in the pthreads library.
Steps To ReproduceUsing an Intel i7-4770 processor (without a K suffix), and eglibc 2.19.1 build Mercury with GRADE=asm_fast.gc.par.stseg in the Mmake.params file (I was doing this to test parallel profiling). The resulting compiler will intermittently crash.
Additional InformationMercury is not the only program to have a bug like this show up with the new libc. libtirpc has a similar problem. If you use Debian testing and NFS (or anything with portmap), then upgrading libtirpc from sid will fix this.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000722

pbone (administrator)

Committed a workaround.
+Notes

-Issue History
Date Modified Username Field Change
2014-06-16 12:10 pbone New Issue
2014-06-16 12:10 pbone Status new => assigned
2014-06-16 12:10 pbone Assigned To => pbone
2014-06-30 15:06 pbone Note Added: 0000722
2014-06-30 15:06 pbone Status assigned => resolved
2014-06-30 15:06 pbone Resolution open => fixed
+Issue History