-1

I have to debug a segfault in my C++ program using Code::Blocks. Unfortunately, the stack trace isn't showing correctly, instead I see ?? ()

Here is a minimal example:

#include <iostream>

using namespace std;

int main()
{
    int *plop;
    cout << *plop << endl;
    return 0;
}

The debugger says:

Program received signal SIGSEGV, Segmentation fault. In ?? () ()

But I was expecting something more useful like "In main ()"

EDIT: here is the build log, if it helps

-------------- Build: Debug in tests (compiler: GNU GCC Compiler)---------------

g++.exe -Wall -fexceptions -g -O -pedantic -Wextra -std=c++0x -std=c++14  -c D:\C\tests\main.cpp -o obj\Debug\main.o
D:\C\tests\main.cpp: In function 'int main()':
D:\C\tests\main.cpp:8:14: warning: 'plop' is used uninitialized in this function [-Wuninitialized]
     cout << *plop << endl;
              ^
g++.exe  -o bin\tests.exe obj\Debug\main.o  -s  
Output file is bin\tests.exe with size 542.00 KB

2nd EDIT: finally solved :)

For those who came here by google : strip symbols -s and Optimizer -O compiler options were checked in my case, theses options conflicts with -g as they removes debug symbols in compiled code.

Thanks for everyone for answering

David
  • 1
  • 1
  • 3
  • 1
    os, compiler (gcc/mingw), compiler version. etc. also http://stackoverflow.com/questions/5870038/uninitialized-pointers-in-code and why ?? here > http://stackoverflow.com/questions/8437526/only-question-marks-in-backtrace-reported-by-gdb-on-arm – strangeqargo Jul 02 '16 at 18:55
  • As some of you stated, the problem is about the debugger and not about the posted code. – David Jul 02 '16 at 19:38
  • About Config: Windows 7; Code::blocks 16.01; Mingw w/ gcc 4.9.2; Project build target is in debug mode – David Jul 02 '16 at 19:40
  • I've updated Jesper's answer. (http://pastebin.com/KHwimTtR) – strangeqargo Jul 02 '16 at 19:52
  • I tried to update it, kek, but you get the point, I hope – strangeqargo Jul 02 '16 at 20:07
  • Check the build log to ensure that the compiler actually gets `-g` flag. – HolyBlackCat Jul 02 '16 at 20:17
  • @strangeqargo but just adding one example of what UB does, does not really add any substance. Different compilers will do different things. The point is it is *undefined* and you can't trust anything, not even the debugger (since it is at the mercy of the compiler - which can do *whatever* it pleases). A single example does not make a material difference to that argument. – Jesper Juhl Jul 02 '16 at 20:20
  • @JesperJuhl I'm sure it depends not only on compiler but on OS too. C++ is close to the iron and low-level OS interfaces. Anyway, I hope someone learned a lesson about UB today – strangeqargo Jul 02 '16 at 20:29
  • I don't see how the OS would influence the code the compiler generates. – Jesper Juhl Jul 02 '16 at 20:35
  • Thanks for the build log. Of course it does not work! `-g` is not compatible with `-O1/2/3`. Your `-O` is equivalent to `-O1` and might make debugging glitchy. Remove the `-O` and try again. Also, remove `-s`. I'm not sure, but it may cause problems with debugging too. Someone please correct me if I'm wrong about the second one. – HolyBlackCat Jul 02 '16 at 20:42
  • @JesperJuhl author compiled with mingw, it's a windows verison of g++ basically, he ran it on windows and got `?? ()` in debugger. I compiled his code on Linux, using g++. On my build gdb outputs error in `main`, not just `?? ()` Same compiler, different OS, different UB. Different libraries, memory & security models, etc. – strangeqargo Jul 02 '16 at 20:42
  • No. Not same compiler. Not at all. Sme compiler version mybe, but build for different OS and targeting different OS. Not the sme thing by a long shot. That's still the compiler generating different code, not the OS influencing UB. – Jesper Juhl Jul 02 '16 at 21:15

2 Answers2

0

you must initialize the int *plop; pointer like bellow, then print the value :

#include <iostream>

using namespace std;

int main()
{
    int *plop = new int(15);
    // *plop = 120; // you can change the plop value as custom
    cout << *plop << endl;
    return 0;
}

result will be : 15

BattleTested_закалённый в бою
  • 4,037
  • 5
  • 26
  • 47
-1

You are dereferencing an uninitialized pointer. That's undefined behaviour and your program is meaningless.

The compiler is free to generate whatever it pleases (including code causing a segfault or not doing anything at all) - basically, all bets are off and you can trust nothing and you can't even count on your debugger showing you anything sane since it just has to work with what the compiler generated - which could be whatever. Don't work with uninitialized variables / invoke UB.

Jesper Juhl
  • 30,449
  • 3
  • 47
  • 70
  • Currious as to the downvote. What exactely do you take issue with with my answer? – Jesper Juhl Jul 02 '16 at 19:00
  • 1
    The question is not what's wrong with the code but why the debugger shows no method name – Thomas Weller Jul 02 '16 at 19:16
  • How *can* the debugger reliably show a method name? It is completely at the mercy of what the compiler generated. And since the code contains UB the compiler is well within its right to generate garbage that the debugger cannot use to produce sensible output. That's just a fact of life you have to learn to deal with and then try to not invoke UB in your code. What else is there to say? And I don't see how that fact makes my answer (pointing out the fact) deserve a downvote. – Jesper Juhl Jul 02 '16 at 19:18