[parsec-users] Segmentation Fault for freqmine

Christian Bienia cbienia at CS.Princeton.EDU
Fri Jan 16 14:53:24 EST 2009

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

parsec-users mailing list
parsec-users at lists.cs.princeton.edu

More information about the parsec-users mailing list