I'm using callgrind to profile a small piece of code. Callgrind output files are well generated, their content looks ok, but I'm unable to open them with kcachegrind: I get the following error message:
Could not open file "callgrind.out.4953". Check it exists and you have enough permissions to read it.
I have all permissions on files and directories they are in, but with the same issue. Also, it works well with an other project, in an other folder in the same workspace. I also precise that the processes terminate correctly in both cases.
I recently reported to the kcachegrind developer a problem with exactly the same symptoms. The problem is triggered when callgrind is used with a very long command line. This was fixed in the next versions of valgrind/callgrind and kcachegrind.
Find below the commit log for the valgrind side.
Waiting for the new releases of valgrind and kcachegrind, if your problem
is also due to a too long command line, you can just edit the file and truncate the cmd: line.
If your problem is not the length of the cmd line, then I guess you will need to use callgrind_annotate (if this work) or further investigate why kcachegrind finds your file problematic.
Author: weidendo Date: Tue Jan 10 20:21:21 2017 New Revision: 16196
Log: Add a format marker to callgrind files
KCachegrind currently uses a quick format detection before actually
loading a file, and checks for a line starting with "events:" in the
first 2kB for that. This obviously is fragile, as shown by an internal
bug report by Philippe: before the "events" line, Callgrind puts a
"cmd:" line with the command line. If this is very long, the detection
fails and the file does not get loaded at all.
While KCachegrind would not need to have this quick format check at
all, it is useful if multiple input format filters get supported at
some point, to automatically select the correct filter.
Further, for the "file" command, for file managers and desktop
environments, having an unique way to detect a file format is
important.
It is not too late to fix this issue for the callgrind format.
Related
With a colleague, we are working on this github repo. When I knit manuscript.Rmd, I get an error "Unable to load picture or PDF file 'nwr.by.freq.ITEM'." as in this commit. When she knits it, it works fine, as in this commit.
The error comes after all chunks have been done, so it's not a problem within R/RStudio. (Plus, we are using renv, and I already checked for discrepancies between versions of our R, Rstudio, and packages.) The problem must come from knitting, so in the pandoc stage or thereabouts.
Given that we have some phonetic symbols (which is why we need to generate the figure in a png, and then read it back in), we are using xelatex as our engine, as recommended here. I don't think these symbols are the problem -- but I do suspect the issue is a divergence between her latex engine and mine. I'm not totally sure how to check for that...
(I'll be trying to answer my own question, so you can just wait and see if I crack this alone!)
To begin with, I updated xelatex, which led to a missing apa6.cls error. Following papaja install instructions, I would ideally re-install mactex -- but while it downloads (since it takes 1h), I just installed tinytex with tinytex::install_tinytex(). At my first attempt to knit the document after that, tinytex downloaded many things. And then the knit went through! Problem solved.
I just installed Sympol in my Ubuntu. Sympol is an open source software in the mathematics. My problem is that when I run sympol on some input data, I don't know where the output is printed. here in page 6 of this pdf (http://www.math.uni-rostock.de/~rehn/software/sympol-manual-0.1.pdf), it says the output is in .ine or .ext format but I don't know where is these output files!!!!!! please help me if you understand how it works. and it is the website of sympol for installation. http://www.math.uni-rostock.de/~rehn/software/sympol.html
I should add that when it says: Segmentation fault
Ubuntu: Assuming your app is actually running properly and you have root permissions, open another terminal, install and run fatrace, and watch for file output. When running, fatrace prints all files touched in real-time, so you should be able to see your output file's location if it's getting output.
Reading the docs again and again is almost always the correct answer, but if in this case the documentation is that bad, then watching for the file getting written is another good way to figure it out.
Windows: Sysinternals procmon (you can get it from Microsoft) can achieve the same result.
I've written a small test program which throws a C++ exception. I've setup Breakpad to write a minidump on this thrown exception. I now have a .dmp file I'd like to see the stack trace for. Several references indicate I should.
Generate a .sym file using Breakpad's 'dump_syms' utility program, which I've done. I'm running dump_syms on the debug binary (which should have the debug symbols built in?). ./dump_syms breakpad_testing > breakpad_testing.sym
At this point I have the .dmp file and the .sym file
Inspect the first line of the .sym file to view to get a binary version hash? This will look something like this -
MODULE mac x86_64 ED3C7C3C3C283C749036117557E0A8500 breakpad_testing.
Use this to create an expected folder structure mkdir -p
./symbols/breakpad_testing/ED3C7C3C3C283C749036117557E0A8500 and
move the .sym file there. mv breakpad_testing.sym
./symbols/breakpad_testing/ED3C7C3C3C283C749036117557E0A8500
Show stack using 'minidump_stackwalk' tool. minidump_stackwalk
breakpad_testing.dmp ./symbols
However these steps don't seem to have any effect on the output of minidump_stackwalk, I still see output lines such as minidump.cc:2122: INFO: MinidumpModule could not determine version for /Users/mb/Library/Developer/Xcode/DerivedData/<blah>/Build/Products/Debug/breakpad_testing and an unsymbolicated stack trace.
Is there something I'm misunderstanding or not using properly regarding Breakpad on OSX?
This is one of the references I've been following https://blog.inventic.eu/2012/08/qt-and-google-breakpad/
In c or c++ While debugging a core dump,i.e., if we are left with a coredump file and try to debug using that core file is there a way we can see the last few lines of code before the dump occured.the stack trace only shows the function call.
for eg:during debugging a running process in dbx or gdb list command
list Display lines of a source file
will give the part of the code currently under execution.in the same way do we have the option while looking into a core dump?
i am working on solaris mdb
The list command in gdb should provide details of source code line numbers and the corresponding source listing from a core file if:
The executable was compiled with debug symbols enabled (eg. -g in gcc and g++)
A non-stripped version of the executable is available (ie. has not had the debug information removed by running strip)
The debugger is able to find the relevant source files
The debugger should still be able to provide file and line numbers even if it is unable to find the source files as the line number information forms a part of the debug symbols. This information should be available through the bt (backtrace) command, as well as the info symbol command.
Note that even if the core file was generated from a stripped executable, as long as you have access to a non-stripped version you can load that in gdb as well as specifying the core file.
Take a look at chapter 13 and 15 of the gdb manual to assist in giving gdb access to your source files.
If you compiled with -g option you can display source lines. In dbx you can use use command to set dbx source directories.
You can use list (l) command to display source lines.
See help command to learn how to use dbx and gdb commands.
If you have set your source path properly using use command in dbx or started it with -I option, then there's hardly any difference between debugging a core dump and a normal process when it comes to reading source lines.
A while ago I changed my personal operating system to linux and my development enviroment to KDevelop.
However debugging c++ projects is still not working as it should.
My KDevelop version is 4.2.2 (I installed it through package management)
Every time I hit the "debug button" the application is starting with the console message
warning: GDB: Failed to set controlling terminal: Operation not permitted and debugging functionality is not available.
Any ideas welcome.
(If you need additional information don't hesitate to ask)
I also had this problem, but I use gdb in KDevelop sparsely enough that hadn't bothered me yet. Here's my log of trying to fix it:
Grepping through the GDB 7.3.1 source code reveals that this message is printed when GDB tries to set its master TTY to a newly-created pseudo-tty (see gdb/inflow.c, lines 683-740). In particular, a call to ioctl with request TIOCSCTTY fails with a permissions error.
With this in mind, I took a look at the Linux kernel source code to see what could cause a failure. A bit of searching shows that it will eventually degenerate into a call to tiocsctty(). The comment from tiocsctty that is important here:
/*
* The process must be a session leader and
* not have a controlling tty already.
*/
Since the only other reason it can fail with EPERM is if the tty that GDB creates is actually a controlling tty for another process (which seems highly unlikely), I thought it reasonable to assume that GDB is not a session leader. Fair enough, it's launched by KDevelop after all!
So: I tried not launching the GDB session in an external terminal, and it works. Problem narrowed down.
Originally, the external terminal line was set to konsole --noclose --workdir %workdir -e %exe. Changing this to terminator -e %exe made a slight difference: KDevelop warned me that
GDB cannot use the tty* or pty* devices.
Check the settings on /dev/tty* and /dev/pty*
As root you may need to "chmod ug+rw" tty* and pty* devices and/or add the user to the tty group using "usermod -G tty username".
I checked my permissions; my user was part of the tty group and all relevant files were readable and writable.
Grepping through the KDevelop source code reveals how KDevelop actually sets up the terminal. It runs the shell script
tty > FIFO_PATH ; trap "" INT QUIT TSTP ; exec<&-; exec>&-; while :; do sleep 3600;done
and then sets up GDB to use the terminal device it reads from FIFO_PATH. (My name, by the way, not the one that KDevelop uses.) The problem (as best I can tell) is that gdb is not launched as a child of the shell script, and thus cannot use it as its main tty.
I'm not feeling up to patching KDevelop to make this work properly as of yet (or finding what actually caused this to stop working in the first place . . .), so the best I can suggest at the moment is to simply not use an external terminal for debugging purposes.
Good luck! I'll update if I find anything useful.
As Arthur Zennig said, for more information, you need to do something
Firstly, you need to create the Terminal profile
Secondly, open Launch Configurations, fill info such as the image below
Good luck!
In case you got the error:
"Can't receive konsole tty/pty. Check that konsole is actually a
terminal and that it accepts these arguments"
RUN > CONFIGURE LAUCHERS > (See picture below. My project name was "loops")
What worked for me was to uncheck checkbox "Use External Terminal". Found the in the "Compiled Binaries" Tab.