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

[Jayaram Bobba <bobba@xxxxxxxxxxx>]

Did you create processor sets before calling pset_bind? If not, I would 
suspect thread migrations as the cause of the
assertion failures...

Jayaram

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.
>
>