Re: [Gems-users] Ruby Segmentation Fault

[Konstantinos Nikas <knikas@xxxxxxxxxxxxxxxxx>]

Hi Jayaram,

we reran our experiments for 8 cores, 2 threads and 
XACT_LOG_BUFFER_SIZE=32, XACT_DEBUG=true and XACT_DEBUG_LEVEL=3. I am 
attaching the output file (There is some more debugging output as we 
have added a print statement to report the log_size for each processor).
Thanks,

Kostis

Jayaram Bobba wrote:
> The segmentation fault seems to occur since ruby does not find the register
> checkpoint for the processor that is trying to restart its transaction...
>
> #0  RegisterState::restoreCheckpoint (this=0x0, m_proc=1) at
>     /home/users/anastop/gems/gems-2.1//common/Vector.h:92
>     #1  0x00002aaab066bc5d in
>     TransactionVersionManager::restartTransaction
>     (this=0xa341340, thread=0, xact_level=1) at
>
> Can get more debug output by setting XACT_DEBUG and XACT_DEBUG_LEVEL?
>
>
> Jayaram
>
>
> Konstantinos Nikas wrote:
>   
> > The code we are running is a transactional workload that we have 
> > developed and we set it up according to the directions provided in the 
> > wiki (bind threads, call set_transaction_registers, etc).
> > The protocol is MESI_CMP_filter_directory as it is the only one LogTM 
> > can use (at least in the latest version of GEMS).
> > Kind regards,
> >
> > Kostis
> >   
> >     
> > > What benchmark are you running and what protocol?
> > >
> > > Polina
> > >
> > > On Thu, Feb 5, 2009 at 12:47 PM, Konstantinos Nikas 
> > > <knikas@xxxxxxxxxxxxxxxxx <mailto:knikas@xxxxxxxxxxxxxxxxx>> wrote:
> > >     Hi all,
> > >
> > >     we have an 8-core CMP and a transactional workload which only uses 2
> > >     threads. We bind the 2 threads to 2 specific processors (avoiding
> > >     always
> > >     core 0). When we set XACT_LOG_BUFFER_SIZE=2048 everything works fine.
> > >     For smaller values (0, 256, 1024) though the simulation fails.
> > >
> > >     At first we used to get the following warning messages :
> > >
> > >     45936462 2 [2,0] endEscapeAction WARNING escape depth < 1. Depth = 0
> > >
> > >     Searching the mailing list we came across a post which suggested
> > >     adding
> > >     a beginEscapeAction() call into hardwareAbort(). We included this
> > >     in our
> > >     code and the warning messages went away. However, the simulations
> > >     still
> > >     fail with a segmentation fault. Gdb reported the following :
> > >
> > >     #0  RegisterState::restoreCheckpoint (this=0x0, m_proc=1) at
> > >     /home/users/anastop/gems/gems-2.1//common/Vector.h:92
> > >     #1  0x00002aaab066bc5d in
> > >     TransactionVersionManager::restartTransaction
> > >     (this=0xa341340, thread=0, xact_level=1) at
> > >     /home/users/anastop/gems/gems-2.1//common/Vector.h:109
> > >     #2  0x00002aaab0656b89 in
> > >     TransactionInterfaceManager::restartTransactionCallback
> > >     (this=0xa341230,
> > >     thread=0) at log_tm/TransactionInterfaceManager.C:751
> > >     #3  0x00002aaaad20fb70 in ?? () from
> > >     /home/simics/academic/simics-3.0.31/amd64-linux/lib/sparc-u3.so
> > >     #4  0x00002aaaad1aed99 in ?? () from
> > >     /home/simics/academic/simics-3.0.31/amd64-linux/lib/sparc-u3.so
> > >     #5  0x00002aaaad1aec9a in ?? () from
> > >     /home/simics/academic/simics-3.0.31/amd64-linux/lib/sparc-u3.so
> > >     #6  0x00002b1b49bc2eaf in SIM_continue () from
> > >     /home/simics/academic/simics-3.0.31/amd64-linux/bin/libsimics-common.so
> > >     #7  0x00002b1b49b83a9c in ?? () from
> > >     /home/simics/academic/simics-3.0.31/amd64-linux/bin/libsimics-common.so
> > >     #8  0x00002b1b4aaf739c in PyCFunction_Call (func=0x2aaaaab26560,
> > >     arg=0x2aaaac9f6a50, kw=0x0) at /home/packages/python-2.4.2 .......
> > >
> > >     Any ideas? Or suggestions how to debug more efficiently?
> > >
> > >     Kind regards,
> > >
> > >     Kostis
> > >
> > >     PS: A similar situation occurs when we run the same 2 threads on a
> > >     4-core machine. It works fine for XACT_LOG_BUFFER_SIZE=0,256,1024,2048
> > >     and fails for size=32!
> > >
> > >     _______________________________________________
> > >     Gems-users mailing list
> > >     Gems-users@xxxxxxxxxxx <mailto: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.
> > >
> > >
> > > ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > 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.
> > >
> > >   
> > >     
> > >       
> > _______________________________________________
> > 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.
> >
> >   
> >     
> _______________________________________________
> 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.
>   
--
Dr. Konstantinos Nikas
Computing Systems Laboratory
School of Electrical and Computer Engineering
National Technical University of Athens

Tel: +30-210-7722495
e-mail: knikas@xxxxxxxxxxxxxxxxx
http://www.cslab.ece.ntua.gr/~knikas

Attachment: output.err.buffer32.procs8.tar.gz
Description: GNU Zip compressed data