dataOut.build_patches() unknown exception

[helmut....@ingenieurbuero-mbi.de]

Hi all again,

once again I´m stuck, sorry.

My proble is that I want to compute the flux inside an area that I know the conductivitie (as part of problem description) and the temperature (solution).

Now I try to compute the flux inside a dataPostprocessor Object, as is shown in step-29 example, because I need it just for visualisation.

ComputeIntensity<2> intensities; //implementation of class exactly as in step-29

    DataOut<2> my_data_out;
    my_data_out.attach_dof_handler(dof_handler);

    std::vector<std::string> solution_names;
    solution_names.push_back("Temperatur");

    my_data_out.add_data_vector(solution, solution_names);
    my_data_out.add_data_vector(solution, intensities);
   
    my_data_out.build_patches();  // aborts !

    std::ofstream output2("solution.vtk");
    my_data_out.write_vtk(output2);

The code compiles fine (gcc-mp-4.7) on different machines.

I adapted the example of step-29 exactly,  the call to add_data_vector works, but the call to build_patches leads imediately to an unknow exception.

libc++abi.dylib: terminate called throwing an exception

I´m not able to debug the program any further, the termination occurs immediately, I can´t get more information from the exception.

Does anybody has an Idea what could lead to this behaviour ?

Btw. step-29 compiles and run without any problem, so I think it can´t be a problem of the libc++abi.dylib.

I have no more ideas ....

Sincerly

Helmut

[Timo Heister]

Run it in a debugger like gdb in debug mode so you can give us the
call stack. Additionally, use a tool like valgrind to check if you are
overwriting any memory.

> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dealii+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Timo Heister
http://www.math.tamu.edu/~heister/

[helmut....@ingenieurbuero-mbi.de]

Am Samstag, 1. Juni 2013 20:31:42 UTC+2 schrieb Timo Heister:

Run it in a debugger like gdb in debug mode so you can give us the
call stack. Additionally, use a tool like valgrind to check if you are
overwriting any memory.

Hi Timo,

thank you for your attention,

unfortunately I´m not sure how to produce the information you requested. I run it under xcode, gdb connected. But I don´t know how to produce a stack trace.... sorry. I´m not a software developer.

I think, if no one else has an idea, i´ll strip the code down to a small example to produce the fail, then other people with more skills could have a look.

Or is there a simple way to get the needed information ?

Thanks in advance

Helmut

[helmut....@ingenieurbuero-mbi.de]

back from google, found the backtrace command in gdb.

this yields:

DEAL:cg::Starting value 17.7223
DEAL:cg::Convergence step 39 value 7.14901e-13

libc++abi.dylib: terminate called throwing an exception

Program received signal SIGABRT, Aborted.
0x00007fff980c4212 in __pthread_kill ()
(gdb) backtrace
#0  0x00007fff980c4212 in __pthread_kill ()
#1  0x00007fff95826af4 in pthread_kill ()
#2  0x00007fff9586adce in abort ()
#3  0x00007fff981f3a17 in abort_message ()
#4  0x00007fff981f13c6 in default_terminate ()
#5  0x00007fff96716887 in _objc_terminate ()
#6  0x00007fff981f13f5 in safe_handler_caller ()
#7  0x00007fff981f1450 in std::terminate ()
#8  0x00007fff981f25b7 in __cxa_throw ()
#9  0x0000000115d837bd in tbb::captured_exception::throw_self (this=0x118501960) at tbb_exception.h:224
#10 0x0000000115e01522 in tbb::internal::generic_scheduler::local_spawn_root_and_wait ()
#11 0x0000000115df9f71 in tbb::pipeline::run ()
#12 0x0000000115dfa01b in tbb::pipeline::run ()
#13 0x00000001031edf1c in dealii::WorkStream::run<std::_Bind<std::_Mem_fn<void (dealii::DataOut<2, dealii::DoFHandler<2, 2> >::*)(std::pair<dealii::TriaIterator<dealii::DoFCellAccessor<dealii::DoFHandler<2, 2>, false> >, unsigned int> const*, dealii::internal::DataOut::ParallelData<2, 2>&, dealii::DataOutBase::Patch<2, 2>&, dealii::DataOut<2, dealii::DoFHandler<2, 2> >::CurvedCellRegion)> ()(dealii::DataOut<2, dealii::DoFHandler<2, 2> >, std::_Placeholder<1>, std::_Placeholder<2>, std::_Placeholder<3>, dealii::DataOut<2, dealii::DoFHandler<2, 2> >::CurvedCellRegion)>, std::_Bind<void (*()(std::_Placeholder<1>, std::reference_wrapper<std::vector<dealii::DataOutBase::Patch<2, 2>, std::allocator<dealii::DataOutBase::Patch<2, 2> > > >))(dealii::DataOutBase::Patch<2, 2> const&, std::vector<dealii::DataOutBase::Patch<2, 2>, std::allocator<dealii::DataOutBase::Patch<2, 2> > >&)>, std::pair<dealii::TriaIterator<dealii::DoFCellAccessor<dealii::DoFHandler<2, 2>, false> >, unsigned int>*, dealii::internal::DataOut::ParallelData<2, 2>, dealii::DataOutBase::Patch<2, 2> > ()
#14 0x00007fff5fbfe770 in ?? ()
Previous frame inner to this frame (gdb could not unwind past this frame)

I´m unsure if this could help...

Helmut

[Timo Heister]

It crashes inside the TBB. You can disable multithreading using -D
DEAL_II_WITH_THREADS=OFF (deal 8.0pre) or --disable-threads (deal
7.3).
You are running on mac os? Not sure if TBB works there for anyone else.

[helmut....@ingenieurbuero-mbi.de]

Hi Timo,

Yes, I work on MacOS (older MacPro, 8 cores, and iMac) normaly without any problem.
The step-29 example works without any problem on the sam machine.

I use deal.II 7.3 . I assume I have to set the option --disable-threads during the build of the libs.
I´ll give it a try.

Thank you very much!

Cheers, Helmut

[helmut....@ingenieurbuero-mbi.de]

Ok, i recompiled the deal-II lib with option -disable-threads.
The program stops now at the same positions, but the console messages say a bit more:

DEAL:cg::Convergence step 39 value 7.14901e-13

terminate called after throwing an instance of 'dealii::StandardExceptions::ExcPureFunctionCalled'
  what():  --------------------------------------------------------
An error occurred in line <37> of file </Users/hm/libs/deal.II-gcc47/source/numerics/data_postprocessor.cc> in function
    void dealii::DataPostprocessor<dim>::compute_derived_quantities_scalar(const std::vector<double>&, const std::vector<dealii::Tensor<1, dim> >&, const std::vector<dealii::Tensor<2, dim> >&, const std::vector<dealii::Point<dim> >&, std::vector<dealii::Vector<double> >&) const [with int dim = 2]
The violated condition was:
    false
The name and call sequence of the exception was:
    ExcPureFunctionCalled()
Additional Information:
(none)
--------------------------------------------------------

Perhaps this gives someone a clue what went wrong, or - with other words - what is my mistake ...

Thanks,

Helmut

[helmut....@ingenieurbuero-mbi.de]

As the mentione line reads:

AssertThrow(false,ExcPureFunctionCalled());

the abort seems to be correct and I assume, that for some reason the (wrong) function is called and not the overloaded function of my code ...

I will not dig in it now, as it is saturday, 23:40 lokal.

Have a good night,

THX

Helmut

[Timo Heister]

Okay, the compiler is not calling your
compute_derived_quantities_scalar() function. Do you provide one in
your class (step-29 provides *_vector() not *_scalar())? Is your
quantity a scalar or a vector? I you think you provide the correct
function, make sure it has the exact same signature as the one in the
base class.

[Wolfgang Bangerth]

I wrote up my strategy for finding what's happening here:

https://code.google.com/p/dealii/wiki/FrequentlyAskedQuestions#The_program_aborts_saying_that_an_exception_was_thrown,_but_I_ca

You've already found what your problem is, but this may nevertheless help.

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@math.tamu.edu
www: http://www.math.tamu.edu/~bangerth/

[helmut....@ingenieurbuero-mbi.de]

Hi Timo, hi Wolfgang,

yes, indeed, my problem is solved so far : i implemented the function for vectors, but the scalar one was called. I was wrong, when I thought, that my solution-vector would be a vector with only one component and that the opportunity to use vector or scalar would be only for comfort reasons - it isn´t. So, obviously my fault and now I have learned something new.

I´ll read into the link Wolfgang has mentioned, and I´m sure there will be further new stuff to learn :)

I´m not sure about what Timo stated with regard to TBB and Mac : I have not found any hint by searching, TBB is anounced to work "everywhere", but never the less it has killed the usefull exception. I wold not like to miss most of the power of my machines by --disable-threads or at least some usefull exceptions by --enable-threads.
 Does TBB has any other bad effects on Mac, as Timo stated ?

Btw, how can a thread be marked as solved ?

Thanky you all, for your work and your attention to my problems,

sincerly Helmut

> I�m unsure if this could help...

[Timo Heister]

> I´m not sure about what Timo stated with regard to TBB and Mac : I have not
> found any hint by searching, TBB is anounced to work "everywhere", but never
> the less it has killed the usefull exception.

Well, me (and many others) are running deal.II under linux
exclusively. You are right though that TBB should work.

> I wold not like to miss most
> of the power of my machines by --disable-threads or at least some usefull
> exceptions by --enable-threads.

Are you sure that you compiled the program in debug mode when you
posted the call stack at the beginning (with TBB)? I would think you
would get the correct exceptions no matter if you are using TBB or
not.

> Does TBB has any other bad effects on Mac, as Timo stated ?

if it works, no. From your call stack it looked like the application
crashed inside TBB, that is why I suggested trying without.

> Btw, how can a thread be marked as solved ?

Not at all, I think.

[Wolfgang Bangerth]

> Are you sure that you compiled the program in debug mode when you
> posted the call stack at the beginning (with TBB)? I would think you
> would get the correct exceptions no matter if you are using TBB or
> not.

I believe the exception is thrown in DataPostprocessor when called on a
side-thread (created by the TBB) and then propagates to the TBB function that
was called on that thread. This function doesn't know what to do with it (it
can't pass it on to the main thread, after all) and so terminates the program
by throwing an exception of itself which then terminates the program.

>> Btw, how can a thread be marked as solved ?

A thread is just a sequence of machine instructions. If this sequence comes to
an end, the thread ends and is terminated by the operating system. Or do you
ask whether it is possible for one thread to terminate another thread?

[Timo Heister]

>> Are you sure that you compiled the program in debug mode when you
>> posted the call stack at the beginning (with TBB)? I would think you
>> would get the correct exceptions no matter if you are using TBB or
>> not.
>
> I believe the exception is thrown in DataPostprocessor when called on a
> side-thread (created by the TBB) and then propagates to the TBB function
> that was called on that thread. This function doesn't know what to do with
> it (it can't pass it on to the main thread, after all) and so terminates the
> program by throwing an exception of itself which then terminates the
> program.

Okay, then he should be able to see the real call stack when using gdb
and 'catch throw'.

>>> Btw, how can a thread be marked as solved ?
>
> A thread is just a sequence of machine instructions. If this sequence comes
> to an end, the thread ends and is terminated by the operating system. Or do
> you ask whether it is possible for one thread to terminate another thread?

I might be wrong, but I think Helmut is asking if this email thread
can be marked as "solved". :-)

[helmut....@ingenieurbuero-mbi.de]

Hi all,

I´ll check out what was mentioned here, perhaps the program was linked to the non-debug lib. It looks like it could be helpful to be more familiar with gdb and the whole compiling/lib stuff.

And yes, Timo is right, I wanted to ask with regard to the mail thread within google groups, not to terminate TBB threads :)