On Thursday 15 April 2010, Milian Wolff wrote:
> On Thursday 15 April 2010 14:14:32 Josef Weidendorfer wrote:
> > Hi Milian,
> >
> > On Thursday 15 April 2010, Milian Wolff wrote:
> > > When I try to profile the whole startup of KDevelop using callgrind, I
> > > and at least one of the other developers, get a reproducible segfault.
> > > This does not occur in memcheck or massif, so I fear it shows a bug in
> > > callgrind itself.
> >
> > Best is to file a bug report.
>
> Even if I have no debug information at all? no backtrace, no useful debug out
> put ;-)
But there must be an output of Valgrind. That's a start.
IMHO a reproducable crash for KDevelop startup is worth a bug report. Just
describe the context as good as possible for others (eg. me ;-) to be able
to reproduce it, too.
It sounds like callgrind could get confused with the mmap/munmap'ping of
the multiple modules - just a quick guess.
> That's why I thought I'd ask here first.
>
> > > How does one debug that? gdb -> valgrind -> app?
> >
> > In Valgrind sources, there is info about this in README_DEVELOPERS in the
> > toplevel directory. In addition to the info there, when starting the
> > tool executable in the debugger directly, one still also should provide
> > the "--tool=..." parameter in my experience. Hmm... should be added there.
> >
> > > That segfaults even earlier and gives a totally useless backtrace without
> > > any debug info...
> >
> > With callgrind, it could help to have the debug output produced by
> > --ct-verbose=... before the segfault.
>
> Do I need a newer callgrind/valgrind version for that? This option is not
> known in Valgrind 3.5.0 and I can't find anything in man valgrind either? Do
> you mean plain --verbose ?
It is there since the beginning ;-)
This actually is a command line option of just callgrind, and it is part of the
debug options. If you run
valgrind --tool=callgrind --help-debug
you get at the end a section about "debugging options for Callgrind".
As these are internal debug options only useful for developing/debugging the
tool,
it makes not much sense to document them for the regular user.
With --ct-verbose=1 you get a trace of function calls as observed by callgrind.
With --ct-verbose=2 you get a more detailed trace of executed basic blocks with
flow control changes amoung them, as well as some other information.
With higher numbers, the debug output gets even huger. You can redirect the
debug output (on stderr) to a file. It could be useful to see the last 100 lines
e.g. of --ct-verbose=5.
The big problem with VG tools and gdb is that, as Philippe already said, VG
has its own SEGFAULT handler, which is called regularily, and quite frequently.
So, README_DEVELOPERS suggest to ignore SEGFAULTs in gdb. This way, you of
course
can not easily get to the real problematic SEGFAULT.
Josef
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
