On Mon, Feb 9, 2015 at 2:53 PM, Paul T. Bauman <ptbau...@gmail.com> wrote:
> So it looks like gdb_backtrace() makes a system() call to print the stack
> trace info from gdb. Does the system() call not inherit the environment
> from that which launched libMesh-based application?
>
> I ask because I've noticed that this will hang if I have a local version
> of gdb loaded in my environment, e.g. I've compiled a newer GDB than what's
> on my system, made a module, and loaded that module such that it's in the
> front of my $PATH. If I don't have that newer gdb version loaded,
> everything is fine - the stack trace prints as it's supposed to and all is
> well.
>
> So, if I'm understanding the issue correctly, would be there interest in
> me adding a --with-gdb configure option that would call a user supplied gdb
> version?
>
> My motivation is that this hang can be really annoying because if it's
> hanging during a make check, I have to manually kill the process, ctrl-c is
> insufficient.
>
gdb_backtrace() isn't the most robust thing in the world... we have also
had some issues with it on our clusters here.
There are better ways of launching external programs than by using the
system() command. I saw some examples using execvp with fork but they were
more complicated, so I went with the simplest solution.
I think the gdb_backtrac() capability should probably be disabled by
default... while it can be useful for providing line numbers where the
backtrace() call does not, the potential benefit does not outweigh a hung
code during a crash in my opinion.
That said, the ability to specify what gdb to use would also be a useful
enhancement, especially if it fixes the problem for you...
--
John
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
