On Wed, Aug 26, 2015 at 4:23 PM, Michael Povolotskyi <mpovo...@purdue.edu>
wrote:

> What happens is as follows:
> I use the gdb editor.
>

Ah, so it's a debugging issue, not a runtime issue...




> I run the code there until the exception is thrown. Since it is not caught
> inside the code, the code stops and I use gdb command "up" and "print" for
> debugging.
> Usually my stack depth is less than 10, so this is easy.
>

And this only works when exceptions are *disabled* in libmesh?  Because
this is about how it works for me when exceptions are enabled too.



Now, when your handler is called the depth has been increased up to 100
> levels and somehow I got into destructors of my objects. Doing "up" command
> many times I was able to get to my exception throwing place, so I could
> debug, but this was inconvenient.
> May be there is a problem in my code, I do not know.
>

And this is an *uncaught* exception, correct?  I suppose it's possible that
your implementation actually unwinds the stack for an uncaught exception (I
have never seen an implementation that does this) and that's why you are
seeing all the extra frames...

By the way, you can always type "frame n" in gdb to go directly to the
frame you want, avoiding typing "up" dozens of times,
https://sourceware.org/gdb/onlinedocs/gdb/Selection.html

-- 
John
------------------------------------------------------------------------------
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Reply via email to