0

I'm studying one project in C++. It's quite big, build is created with cmake. After installing all dependencies and libs it's the build is done fine. But when I run it, I get Segmentation fault.

Here is the thing: There is no IDE, running this project with cmake in VS Code. I wonder if it's possible to find this place in code which causes Segmentation fault. I know that there is GDB debugger for such things. I run several commands and here's what I get:

gdb build/studpark
...
Reading symbols from build/studpark...
(gdb) run
Starting program: /Users/admin/Downloads/StudPark-develop/build/studpark 
[New Thread 0x2503 of process 7316]
[New Thread 0x1903 of process 7316]
[New Thread 0x1a03 of process 7316]
warning: unhandled dyld version (17)

Thread 3 received signal SIGSEGV, Segmentation fault.
0x00007ff809bec6b2 in ?? ()

(gdb) backtrace
#0  0x00007ff809bec6b2 in ?? ()
#1  0x00007ff7bfeff510 in ?? ()
#2  0x0000000100002abe in main ()
Backtrace stopped: frame did not save the PC

The question is: Is it possible to trace and find exact place in code that causes segmentation fault?

EDIT: I compile my project with these flags:

set(CMAKE_CXX_FLAGS "-stdlib=libc++ -g")

My platform is Mac OS.

Alex_Werben
  • 63
  • 6
  • 3
    I think you did not compile the binary with debug symbols hence no stacktrace. Add `-g3` to the compilation flags. Consider disabling optimizations with `-O0` or `-Og` if you are running into "optimized_out" or if the debugger starts skipping some lines. – Quimby May 12 '22 at 19:11
  • You'll need to compile with `-g` and you will want to consider using the tool `valgrind` along with `gdb`. https://valgrind.org/ – BadZen May 12 '22 at 19:12
  • Also you need to sign your code on Darwin, if you want to debug a binary. (I'm assuming this is the reason for your unhandled dyld - if not on Darwin, ignore) – BadZen May 12 '22 at 19:15
  • 1
    @BadZen I'm running on mac so ```valgrind``` it not an option. – Alex_Werben May 12 '22 at 19:16
  • @BadZen after installing GDB I created signed GDB certificate. So I believe something else should be done. What do you think? – Alex_Werben May 12 '22 at 19:19
  • 2
    gdb on macOS is not really a thing anymore. Use lldb. – sweenish May 12 '22 at 19:21
  • `valgrind` runs on mac / OSX. There's a brew. See the homepage I linked, or google around. (There were a couple of versions of Sierra that it was sketchy / broken on IIRC) – BadZen May 12 '22 at 19:23
  • 1
    You shouldn't be hardcoding debug flags into your cmake project; instead use the `Debug` configuration that is already available. (E.g. assuming you use a single configuration generator pass `-D CMAKE_BUILD_TYPE=Debug`). [Cmake presets](https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html) would probably result in a better integration into vs code though. *"There is no IDE, [I'm] running this project [...] in VS Code."* VS code has many extensions including some for debugging using gdb making it imho effectively an IDE... – fabian May 12 '22 at 19:25
  • @BadZen I tried installing ```valgrind``` earlier this year but it's behaviour was unexpected. Using brew, output is: valgrind: Linux is required for this software. Error: valgrind: An unsatisfied requirement failed this build. – Alex_Werben May 12 '22 at 19:28
  • The trouble `Segmentation fault` even if you find the point where it crashed that usually does not help you find the problem as the data was probably corrupted somewhere else and your code just stumbled on the issue of the corrupted data. – Martin York May 12 '22 at 19:36
  • 1. Print out the map file from the linker. This will give you all the addresses of public symbols. 2. In the dump file, get the last know executable address. 3. Search the map file for the lowest closest address and the highest closest address. 4. Get the names of these functions. 5. Search the code for these functions. – Thomas Matthews May 12 '22 at 19:47
  • @AcidDica - tap https://github.com/LouisBrunner/homebrew-valgrind maybe, depends on your os version – BadZen May 12 '22 at 19:51
  • @BadZen It's still an older version that still requires macOS <= High Sierra. valgrind just doesn't work on macOS. It's literally on the homepage that you think supports your view: "X86/MacOSX 10.12 and AMD64/MacOSX 10.12" – sweenish May 12 '22 at 19:55
  • On Mac, there is an `atos` command that maps a crash location to the source line, provided the file has debug info. It comes with the Xcode toolset. Might not like the GCC generated executables, though. – Seva Alekseyev May 12 '22 at 20:03
  • I've personally built and run valgrind on High Sierra, so... yeah. You're looking at old reddit posts or something. Click through to "supported platforms" on the valgrind homepage, by the way. Or actually try it. I'll send them an email to note the front page text needs updating. – BadZen May 12 '22 at 20:05
  • @BadZen Again, you're just agreeing with me. I said <= High Sierra. Have you run on it on Big Sur? Monterrey? Probably not. Because it's not supported. And again, per the page that you think makes you right: "X86/Darwin (10.5 to 10.13), AMD64/Darwin (10.5 to 10.13): supported." So again, valgrind only works on a 5 year old version macOS and nothing newer. – sweenish May 12 '22 at 20:45
  • No official support does not mean it does not run. See https://stackoverflow.com/questions/58360093/how-to-install-valgrind-on-macos-catalina-10-15-with-homebrew or you know... *go ahead and try it*. I even gave an alternate tap that streamlines the process. It works, I promise. You're just arguing for no reason whatsoever from zero or near-zero basis of experience and spamming this question, it seems. Let it go, eh? – BadZen May 12 '22 at 21:11
  • @fabian Thanks, mate! When you wrote about different extensions, I gave a try and found proper ones for my case and it really helped. – Alex_Werben May 14 '22 at 19:06

1 Answers1

0

I've found a solution for my case and here's what I've done:

  1. Installed these VS Code Extensions - CodeLLDB
  2. Added Configuration File: Run/'Add Configuration...'
  3. The config file was at <root_dit>/.vscode/launch.json and looked like this:
{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "lldb",
      "request": "launch",
      "name": "Debug",
      "program": "${workspaceFolder}/build/main",
      "args": [],
      "cwd": "${workspaceFolder}"
    }
  ]
}
  1. In my case I only changed "program": "${workspaceFolder}/build/main" to show path to my executable file.

After doing these actions I was able to run my program in Debug mode with breakpoints which helped me to examine project and find errors in code.

Alex_Werben
  • 63
  • 6