[parsec-users] Segmentation Fault for freqmine

Saugata Ghose sg532 at cornell.edu
Fri Jan 16 15:12:26 EST 2009

Hi Chris:
I just ran Valgrind on it (using Memcheck), and it was unable to find  
anything (even though the program still seg faulted).  I ran it with  
the --leak_check=yes option.  Should I run it with something else?   
Sorry - I've never used Valgrind in the past.


On Jan 16, 2009, at 2:53 PM, Christian Bienia wrote:

> Hi Saugata,
> We are not aware of any segfault problems in freqmine, thanks for  
> letting us
> know about this. From what you say it seems that it might be some  
> sort of
> memory access error that makes a few writes go wild. It's hard to  
> say why it
> happens on one machine but not the other - obviously the memory  
> layout is
> affecting the bug, so it might be something as trivial as a different
> compiler version that makes the bug show up. Fortunately we can  
> exclude data
> races and other concurrency bugs.
> Can you do me a favor? Please run the program with Valgrind
> (http://www.valgrind.org/) or some other memory checker. It might be  
> able to
> point you to the exact location where the bug occurs. If we're lucky  
> we can
> fix it without too much trouble.
> Let me know if I can help you somehow.
> - Chris
> -----Original Message-----
> From: parsec-users-bounces at lists.cs.princeton.edu
> [mailto:parsec-users-bounces at lists.cs.princeton.edu] On Behalf Of  
> Saugata
> Ghose
> Sent: Friday, January 16, 2009 2:44 PM
> To: parsec-users at lists.cs.princeton.edu
> Subject: [parsec-users] Segmentation Fault for freqmine
> I compiled the serial versions of the benchmarks, and ran into a
> problem with the freqmine benchmark.  I was wondering if anyone else
> had encountered it.  On one of my machines, everything compiled fine,
> and the test ran successfully.  However, on the second machine, I
> compiled and executed the test, and freqmine would produce a seg  
> fault.
> I traced this back to the global thread_mapfile variable in
> fp_tree.cpp.  It turns out that when sort is first called, for some
> strange reason, it nulls the thread_mapfile pointer, which in turn
> produces a segmentation fault when the pointer is read next.  The
> nulling seems to happen at the moment sort is called.  If I insert a
> dummy MapFile ** pointer right after thread_mapfile's declaration, the
> program executes fine and produces identical outputs to the run on the
> machine that did not seg fault.
> Has anyone else experienced something similar?  Is there a workaround
> for this?  My suspicion is that the sumntype array is hitting a
> negative index access (indicating incorrect program behavior), but it
> seems odd that this doesn't affect the other build that I have.
> Thanks,
> -Saugata
> _______________________________________________
> parsec-users mailing list
> parsec-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/parsec-users
> _______________________________________________
> parsec-users mailing list
> parsec-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/parsec-users

More information about the parsec-users mailing list