Stacks can't be fully analysed on Sles11 about google-coredumper

[GoogleCodeExporter]

I have the same issue still in the version 1.2.1 from April 2008: 
http://code.google.com/p/google-coredumper/downloads/detail?name=coredumper-1.2.
1.tar.gz&can=2&q=
on SUSE Linux Enterprise Server 11.0 (x86_64). You wrote coredumper.c:192. In 
version 1.2.1, this would be the call to
 ClearCoreDumpParameters(¶ms)
Does anyone (Andy?) have successfully solved this? I would be very thankful for 
any hint before using gdb to try whether this is the point in the coredumper 
lib where the error occurs.

Original comment by [email protected] on 1 Aug 2011 at 3:00

[GoogleCodeExporter]

Since support for this package seems to have evaporated, I considered 
diagnosing the issue myself, but was faced with an unbounded continuation 
engineering task that didn't look very rewarding.  Instead I turned to the gdb 
gcore command.  The sequence is to fork and exec gdb passing a parameter file 
(as the gcore script does) and wait for the child to terminate.  This gives 
much the same results as the coredumper package (except you can't get inside to 
influence dumping shared store segments) but the gdb team do maintain the 
package.  The other downside is that you have to have gdb installed, which may 
be an issue for some sites.  Note there's a problem on SLES11 with gdb gcore 
for which a fix is available (I don't know if that fix fixes the core dumper 
issue as well - the symptoms are again unanalysable stacks).  You can also fork 
and abort to get a dump using kernel.  Shared store can be unmapped to avoid 
dumping it &/or the kernel controls set up for the process.  The downsides are 
you have little control over the file named (by default SLES always use the 
'core' pattern - you can create and switch to a directory to manage this, but 
the site can of course set any pattern they like for the system) and you lose 
all the threads apart from the one you fork from - not so hot in a 
multi-threaded environment.   

Original comment by [email protected] on 3 Aug 2011 at 10:58