I just checked in an updated Makefile for fparser.  It appears to work
properly now with parallel make on our Linux and Mac systems.

Cody

On Tue, Feb 21, 2012 at 7:23 PM, Derek Gaston <fried...@gmail.com> wrote:

> Or maybe do it now... it might fix the problem ;-)
>
> For the record we always just used a straight libMesh contrib style
> Makefile to build FParser in MOOSE.  We junked their stuff almost
> immediately...
>
> Derek
>
>
> On Tue, Feb 21, 2012 at 7:21 PM, Kirk, Benjamin (JSC-EG311) <
> benjamin.kir...@nasa.gov> wrote:
>
>> Good work. I've spent a good bit of the day wrapping all the other
>> contributed sources with automake - ill probably hold off on this one until
>> last.
>>
>> -Ben
>>
>>
>>
>> On Feb 21, 2012, at 5:41 PM, "Cody Permann" <codyperm...@gmail.com>
>> wrote:
>>
>> I finally figured out the why "fparser" is crashing on our Linux
>> machines.  It's been maddening, tracking this bug down since the behavior
>> only manifested itself in certain situations and in optimized mode only.
>>  It was a "Heisenbug" since any attempt to observe the bug would modify
>> it's behavior.  You know you have an issue when even Valgrind crashes with
>> a message "The impossible has happened - Valgrind has received a seg
>> fault!" and then continues to crash too along with the program it is
>> grinding - nice touch!
>>
>> At any rate, it turns out there is a problem with the fparser Makefile
>> which I haven't identified yet but will keep looking.  The problem is easy
>> to repeat on all of our Linux systems.  If you "make clean" in fparser and
>> build, you can immediately type make again and it'll compile
>> "bytecodesynth.cc" once more and relink.  Some part of the build process is
>> either modifying that file or not waiting for that file to compile before
>> linking which is causing the memory corruption issue.  I haven't been able
>> to get the fparser to crash with pure libMesh code either which might be
>> way others aren't seeing it but it's definitely there.
>>
>> Hopefully I can track it down tomorrow with a little more
>> Makefile sleuthing.
>>
>> Cody
>>
>>
>> On Fri, Feb 10, 2012 at 3:59 PM, Cody Permann <codyperm...@gmail.com>wrote:
>>
>>>
>>>
>>> On Fri, Feb 10, 2012 at 3:54 PM, Roy Stogner 
>>> <royst...@ices.utexas.edu>wrote:
>>>
>>>>
>>>> On Tue, 7 Feb 2012, Roy Stogner wrote:
>>>>
>>>> > On Mon, 6 Feb 2012, Roy Stogner wrote:
>>>> >
>>>> >> On Mon, 6 Feb 2012, Kirk, Benjamin (JSC-EG311) wrote:
>>>> >>
>>>> >>> Anyone got a snippet showing how to use the contributed fparser?
>>>> >>>
>>>> >>> We'd love to add that capability to some application code here...
>>>> >>
>>>> >> I'm going to put it into an example, but probably not until after the
>>>> >> System::project_vector changes are committed.  That latter should be
>>>> >> this afternoon or tonight unless anyone pipes up with a problem or
>>>> >> objection.
>>>> >
>>>> > A bit more delay on this - fparser isn't thread-safe by default, and
>>>> > the new project_vector functor interface doesn't play with it in a
>>>> > thread-safe way.  For this and other reasons I'm going to break down
>>>> > and add a FunctionBase::clone() method.
>>>>
>>>> project_vector (and ExactSolution and ExactErrorEstimator) changes are
>>>> done, FunctionBase cloning's done, and I've put a snippet
>>>> demonstrating use (for a single-variable system) into adaptivity_ex5.
>>>>
>>>> It's working correctly for me, but now Cody's got me worried.  Adding
>>>> an Optimize() call doesn't break anything on this end, but maybe
>>>> there's something about my compiler/system/trivial-example that isn't
>>>> triggering whatever problem they're seeing?
>>>>
>>>
>>> I wouldn't worry about it - we are using fparser in a wrapper class and
>>> we could easily be doing something wrong there.  I'll check it out soon and
>>> let you know.
>>>
>>>
>>>> ---
>>>> Roy
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Virtualization & Cloud Management Using Capacity Planning
>>>> Cloud computing makes use of virtualization - but cloud computing
>>>> also focuses on allowing computing to be delivered as a service.
>>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>>> _______________________________________________
>>>> Libmesh-devel mailing list
>>>> Libmesh-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> Libmesh-devel mailing list
>> Libmesh-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>>
>>
>
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to