On Thu, 8 Nov 2012, Roy Stogner wrote:
> I'm seeing hangs on our BuildBot servers when running the
> "-online_mode 1" step of reduced_basis_ex6 with --n_threads=2 in the
> LIBMESH_OPTIONS. That may just be because our BuildBot server is
> ridiculously overloaded, and I'll see if I can verify it
On Wed, 7 Nov 2012, Paul T. Bauman wrote:
There was a small turd at the top of fem_physics.h in the
patch (search for "link"), but after removing that, patch applied
fine for me at r6325. All my GRINS unit/regression tests ran fine in
dbg mode. And examples ran fine with MPI and MPI+TBB.
This
On Thu, 8 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
>> if test `uname` = "Darwin" ; then
>>CXXFLAGS_DBG="$CXXFLAGS_DBG -std=c++0x -Woverloaded-virtual"
>> else
>>CXXFLAGS_DBG="$CXXFLAGS_DBG -std=c++0x -Woverloaded-virtual
>> -D_GLIBCXX_DEBUG -D_GLIBCXX
On Nov 8, 2012, at 3:24 PM, John Peterson wrote:
> Check out compiler.m4:
>
> if test `uname` = "Darwin" ; then
>CXXFLAGS_DBG="$CXXFLAGS_DBG -std=c++0x -Woverloaded-virtual"
> else
>CXXFLAGS_DBG="$CXXFLAGS_DBG -std=c++0x -Woverloaded-virtual
> -D_GLIBCX
On Thu, Nov 8, 2012 at 2:01 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> Wanna show me yours?
--- SUMMARY
---
Package version : libmesh-0.9.0
C++ compiler type.. : gcc4.6
On Nov 8, 2012, at 2:49 PM, John Peterson wrote:
>
>
> On Thu, Nov 8, 2012 at 1:46 PM, Kirk, Benjamin (JSC-EG311)
> wrote:
> I think what John is observing is the flags aren't getting passed through to
> the link step. I can attest (as does make V=1) that they are used during
> compilation
On Thu, Nov 8, 2012 at 1:46 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> I think what John is observing is the flags aren't getting passed through
> to the link step. I can attest (as does make V=1) that they are used
> during compilation:
Nope, what I posted was from the
On Nov 8, 2012, at 2:23 PM, Roy Stogner wrote:
>> Well... on the automake branch I don't believe you get any of those
>> libstdcxx debugging flags, even when METHOD=dbg.
>
> Is John correct about this? Was it an oversight or a deliberate
> change? Trying to debug without the ability to turn o
On Thu, Nov 8, 2012 at 9:34 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> > Definitely try opt mode, that's where I see the segfaults, for example
> in adjoints_ex1. No special LIBMESH_RUN or LIBMESH_OPTIONS, just
> hand-built compilers and no macports. Not sure if it was m
>
> Side question: what's the right way to manually edit compiler flags on the
> automake branch? Looks like I can edit the generated Makefile directly…
Permanently or temporarily?
If the latter,
configure actually doesn't do anything except create config.status, which is
run to create ev
On Thu, Nov 8, 2012 at 12:19 PM, Roy Stogner wrote:
> Have you tried setting options "in between" the opt and debug flags by
> hand? That's was the (successful) last hope for me when such a
> heisenbug hit once - try to figure out whether the breakage is due to
> the optimization flags or the rem
On Thu, Nov 8, 2012 at 12:17 PM, John Peterson wrote:
> OK, so adjoints_ex1 on the automake branch works just fine in DEBUG mode.
> This is consistent with trunk, and what we've seen with hand-built
> compilers and non-libtool linking all along... so no better stack traces
> unfortunately.
Pre
On Thu, 8 Nov 2012, John Peterson wrote:
OK, so adjoints_ex1 on the automake branch works just fine in DEBUG
mode. This is consistent with trunk, and what we've seen with
hand-built compilers and non-libtool linking all along... so no
better stack traces unfortunately.
Have you tried setting
On Thu, Nov 8, 2012 at 11:05 AM, John Peterson wrote:
> On Thu, Nov 8, 2012 at 10:33 AM, John Peterson wrote:
>
>> Any chance you can manually hack -g in there?
>>>
>>> ./configure libmesh_CXXFLAGS="-g"
>>>
>>> will do it I think...
>>>
>>
>> Sure, will try that next, although I claim the stack t
No preference, but the latter trumps the former.
-Ben
On Nov 8, 2012, at 12:06 PM, "John Peterson"
mailto:jwpeter...@gmail.com>> wrote:
On Thu, Nov 8, 2012 at 10:33 AM, John Peterson
mailto:jwpeter...@gmail.com>> wrote:
Any chance you can manually hack -g in there?
./configure libmesh_CXX
On Thu, Nov 8, 2012 at 10:33 AM, John Peterson wrote:
> Any chance you can manually hack -g in there?
>>
>> ./configure libmesh_CXXFLAGS="-g"
>>
>> will do it I think...
>>
>
> Sure, will try that next, although I claim the stack trace will be no more
> illuminating ;-)
Yeah... with -g in optim
On Thu, Nov 8, 2012 at 9:55 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> Any chance you can manually hack -g in there?
>
> ./configure libmesh_CXXFLAGS="-g"
>
> will do it I think...
>
Sure, will try that next, although I claim the stack trace will be no more
illuminating ;
On Thu, Nov 8, 2012 at 9:34 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> But to launch it in the debugger, do
>
> $ libtool --mode=executde gdb ./introduction-ex1
>
> for example.
>
Cool, this works for me. Here is the stack trace for adjoints_ex1 from the
automake branch
On Nov 8, 2012, at 10:29 AM, Roy Stogner wrote:
>
> On Thu, 8 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
>
>> As of yesterday I've added support for the other multithreading use
>> case, asynchronous execution of an operation that would otherwise
>> block. This is commonly used in GUI progra
On Thu, 8 Nov 2012, John Peterson wrote:
The error is an unhelpful stack trace ending in an obscure system
function called misaligned_stack_error_entering_dyld_stub_binder().
It typically only shows up in opt mode, so the stack traces aren't
super-helpful anyway.
This is horrifying. I hereb
On Nov 8, 2012, at 10:21 AM, John Peterson wrote:
>
> It typically only shows up in opt mode, so the stack traces aren't
> super-helpful anyway.
>
> Speaking of stack traces, can anyone recommend a way to run the examples in
> the automake branch through a debugger? I should probably try
>
On Thu, 8 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
As of yesterday I've added support for the other multithreading use
case, asynchronous execution of an operation that would otherwise
block. This is commonly used in GUI programming but not needed as
frequently in scientific computing. Sti
On Wed, Nov 7, 2012 at 3:50 PM, Paul T. Bauman wrote:
> .) On the automake branch, I still get the (system-level) segfaults with
>> my hand-built compilers.
>>
>
> What are the errors?
>
The error is an unhelpful stack trace ending in an obscure system function
called misaligned_stack_error_ente
All -
For a while we've supported the TBB 'task-based' parallelism, whereby a loop is
executed across multiple threads and the results are combined in some way.
As of yesterday I've added support for the other multithreading use case,
asynchronous execution of an operation that would otherwis
24 matches
Mail list logo
