[parsec-users] Segmentation Fault for freqmine

Christian Bienia cbienia at CS.Princeton.EDU
Thu Jan 22 16:58:11 EST 2009


Hi everybody,

The authors of the benchmark program have confirmed Saugata's bugfix. We
will add it to the next version of PARSEC.

- Chris


-----Original Message-----
From: parsec-users-bounces at lists.cs.princeton.edu
[mailto:parsec-users-bounces at lists.cs.princeton.edu] On Behalf Of Christian
Bienia
Sent: Monday, January 19, 2009 3:30 PM
To: 'PARSEC Users'
Subject: Re: [parsec-users] Segmentation Fault for freqmine

Saugata,

That's great news! Congratulations. I'll forward your mail to the authors of
freqmine, they are in the best position to comment on your findings.

- 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: Monday, January 19, 2009 3:06 PM
To: PARSEC Users
Subject: Re: [parsec-users] Segmentation Fault for freqmine

Hi Chris:
I think I've found the error.  When I compiled the benchmark with -O0  
(and -O1 for that matter), the bug disappeared, so I suspect it may  
have to do with the way the global variables are being arranged in  
memory (and therefore continued using -O3).

Anyhow, I think that the parameters being passed into the sort()  
function in fp_tree.cpp (called at line 687) are wrong.  The upper  
bound passed in is hot_node_num, which is the size of the array.   
However, sort uses this upper bound to traverse indices 0 through  
hot_node_num (where the correct range should be 0 through  
hot_node_num-1).  I can only assume that a different memory  
arrangement on the other compiled versions resulted in the word after  
the array being inconsequential, which is why this error didn't show  
up elsewhere.

A quick fix involves changing line 687 from:
	sort(sumntype, ntypeidarray, 0, hot_node_num);
to:
	sort(sumntype, ntypeidarray, 0, hot_node_num - 1);

Does this sound right?  The test output of the fix checks with that of  
the "reference" compilation I have, and Valgrind (using the exp- 
ptrcheck tool, as memcheck doesn't find global array access errors)  
reports no errors.  If you'd like, I can send you the output so you  
can check the values against yours.

Thanks,
-Saugata

On Jan 16, 2009, at 3:34 PM, Christian Bienia wrote:

> Saugata,
>
> First, make sure that all types of checks are enabled. I believe  
> this is
> generally not the case. If memcheck still doesn't show anything you  
> can also
> give it a try with ptrcheck - its functionality overlaps a little  
> with that
> of memcheck, but it uses a different method. You should also make  
> sure that
> freqmine is compiled without optimization and with debugging symbols  
> (-g -O0
> with gcc).
>
> Please let me know of the result.
>
> - 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 3:12 PM
> To: PARSEC Users
> Subject: Re: [parsec-users] Segmentation Fault for freqmine
>
> 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.
>
> Thanks,
> -Saugata
>
> 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
>
> _______________________________________________
> 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

_______________________________________________
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