Re: [Gems-users] TransactionVersionManager.C assertion failed

[Greg Byrd <gbyrd@xxxxxxxx>]

I'm not running the transactional benchmarks, but several of the Splash 
benchmarks will create N-1 threads, and then call the same function from the 
main thread, resulting in N threads running.  Are you sure this isn't happening?
...Greg


Jim Leek wrote:
> Ok, I finally figured this out.  So, for some reason in the 
> transactional microbenchmarks the default setting for number of threads 
> created is "processors-1".  (For example:     "./CHOLESKY -p%d %s\n" % 
> (processors-1, arg_str)])  Which means that if I have 32 processors, 
> cholesky will run with ./CHOKESKY -p31.  I thought this a little odd, 
> but I figured whoever wrote the script probably knew more about it than me.
> Unfortunately, this causes the assertion failure I've been having.  If 
> only 31 threads are launched, set_transaction_registers is only called 
> 31 times, which means  TransactionVersionManager::setLogBase(int thread) 
> is not called for one of the threads.  However, that thread will still 
> be checked in  TransactionVersionManager::addLogEntry.  This is where 
> the assertion failed because m_maxLogSize has not been initialized.  So 
> I mananged to fix that by just using -p32 instead of -p31.
> However, Now I'm getting:
>
> 28 XACT CONSISTENCY CHECKER: FAILED 0x[0xf963e140, line 0xf963e140] 
> ACCESS TYPE: ST IN READ SET OF 14 PC [0x247b8, line 0x24780] RANDOM_SEED 
> 88170
>  PROCESSOR: 14
>  READ SET:  LEVEL 0: [0xf963e140, line 0xf963e140] [0xf963e6c0, line 
> 0xf963e6c0] [0xfde2dd40, line 0xfde2dd40]
>  WRITE SET:
> 28 XACT CONSISTENCY CHECKER: FAILED 0x[0xf963e140, line 0xf963e140] 
> ACCESS TYPE: ST IN READ SET OF 17 PC [0x247b8, line 0x24780] RANDOM_SEED 
> 88170
>  PROCESSOR: 17
>  READ SET:  LEVEL 0: [0xf963e140, line 0xf963e140] [0xf963e6c0, line 
> 0xf963e6c0] [0xfde2dd40, line 0xfde2dd40]
>  WRITE SET:
> 28 XACT CONSISTENCY CHECK FAILURE DUE TO OVERLAP BETWEEN ESCAPE ACTIONS 
> AND TRANSACTIONS  Address: [0xf963e140, line 0xf963e140] PC: [0x247b8, 
> line 0x24780] RANDOM SEED 88170 cycle 1812092
> thread: 0 thread log size: 136max log: 3200000chip: 27
> 19 XACT CONSISTENCY CHECKER: FAILED 0x[0xf963e140, line 0xf963e140] 
> ACCESS TYPE: ST IN READ SET OF 14 PC [0x247b8, line 0x24780] RANDOM_SEED 
> 88170
>  PROCESSOR: 14
>  READ SET:  LEVEL 0: [0xf963e140, line 0xf963e140] [0xf963e6c0, line 
> 0xf963e6c0] [0xfde2dd40, line 0xfde2dd40]
>  WRITE SET:
> 19 XACT CONSISTENCY CHECKER: FAILED 0x[0xf963e140, line 0xf963e140] 
> ACCESS TYPE: ST IN READ SET OF 17 PC [0x247b8, line 0x24780] RANDOM_SEED 
> 88170
>  PROCESSOR: 17
>  READ SET:  LEVEL 0: [0xf963e140, line 0xf963e140] [0xf963e6c0, line 
> 0xf963e6c0] [0xfde2dd40, line 0xfde2dd40]
>  WRITE SET:
> 19 XACT CONSISTENCY CHECK FAILURE DUE TO OVERLAP BETWEEN NONTRANSACTION 
> AND TRANSACTIONS  Address: [0xf963e140, line 0xf963e140] PC: [0x247b8, 
> line 0x24780] RANDOM SEED 88170 cycle 1812139
> Sigh.
>
> Could this have something to do with the fact that pset_bind keeps 
> failing for me?  Perhaps the threads are moving between processors which 
> might screw up ruby in some way? 
>
> Jim
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.