Cannot access memory at address 0x0

[defumar]

Hi, it's me, again (sigh), I'm unsure whether I should post this on the KDevelop forum, the gdb one or qtcentre, so I'll start with the most specific one.
I'm new to working with KDevelop. Yeah, I guess I should read some docs about it. (I normally work with MSVS)

Here's the problem I'm having: I keep getting the following error when trying to debug: Cannot access memory at address 0x0. I've cut down my code and pinned down the problem to be at line 5, yet I'm still puzzled as of why it happens, I can't see what I'm doing wrong here. (naturally, it compiles just fine)

Right, so here's the code.

#include <QApplication>

int main(int argc, char *argv[])
{
QApplication app(argc, argv);

return 0;
}

Specs:
Ubuntu 7.10
KDevelop 3.5.0

[wysota]

Are you sure this is the code that causes trouble? It's perfectly valid. And accessing memory at address 0x0 means you are trying to dereference a null pointer.

[defumar]

I did a clean on the project dir, made the makefile etc again and left only the main.cpp in there and it still keeps giving me that error. I'll try starting a new project and copy pasting it in but this is really weird.

[wysota]

Try compiling and running an empty file.

[defumar]

No error on compilation
No error on debug for the following

int main(int argc, char* argv[])
{
return 0;
}

Unless you meant compiling a truly empty file, 'cus that gave me: (.text+0x18): undefined reference to `main'
which seems normal imo

[jpn]

What's the backtrace when "Cannot access memory at address 0x0" happens?

[defumar]

behold:
(gdb) bt
#0 main (argc=Cannot access memory at address 0x0
) at main.cpp:7
^done

[wysota]

How exactly did you compile the application? What happens if you change "*argv[]" to "**argv"? I know the former should work but it should all work and it doesn't so I'm curious to see the result.

[defumar]

Firstly I went into the src directory of my Simple Qt project and I ran qmake -project and qmake, then I opened up KDevelop again and had it Build Project using all the default settings for a qmake project. (g++)
I tried changing it to ** but still got the same error.

[wysota]

What is the contents of the .pro file?

[defumar]

SUBDIRS += src
TEMPLATE = subdirs
CONFIG += warn_on \
qt \
thread

I read that the -fstack-check option may cause an error like this. I have no idea of where to find it in my KDevelop though.
The page I read this --> http://lists.trolltech.com/qt-interest/2003-06/msg00731.html

[wysota]

What's the contents of the .pro file inside the src subdirectory? :)

Oh, and please rebuild your project without KDevelop. Open the console, cd into src, run qmake, make distclean, qmake, make.

[defumar]

oh right, here it is:

################################################## ####################
# Automatically generated by qmake (2.01a) Fri Jan 25 13:56:09 2008
################################################## ####################

TEMPLATE = app
TARGET =
DEPENDPATH += .
INCLUDEPATH += .

# Input
SOURCES += main.cpp


Right I made it without KDevelop and this is what gdb gave me when stepping through code.

~/MToDo/src$ gdb src
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) break main
Breakpoint 1 at 0x8048596: file main.cpp, line 5.
(gdb) run
Starting program: /home/defumar/MToDo/src/src
[Thread debugging using libthread_db enabled]
[New Thread -1224051008 (LWP 6910)]
[Switching to Thread -1224051008 (LWP 6910)]

Breakpoint 1, main (argc=1, argv=0xbfb26af4) at main.cpp:5
5 QApplication app(argc, argv);
(gdb) n
Qt: gdb: -nograb added to command-line options.
Use the -dograb option to enforce grabbing.
7 return 0;
(gdb) n
8 }
(gdb) n
0xb743b050 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
(gdb) n
Single stepping until exit from function __libc_start_main,
which has no line number information.

Program exited normally.
(gdb) q


backtrace after executing line 5 (evil line, ain't it) returns the same as before (argc=Cannot access mem at 0x0)

[wysota]

From the above output it seems the program executes correctly. Or am I wrong?

[defumar]

The above output shows that the program seems to execute correctly but in a different gdb session I backtraced a couple of times and noticed that after line 5 argc=Cannot access mem at 0x0
Which doesn't seem correct to me though. argc should still be valid as it was at line 5. Instead it shows that apparantly it got corrupted :\ Correct me if I'm wrong.

[wysota]

Could you show us a print from a gdb session that segfaults the project? And are you sure this is not actually gdb that segfaults and not the project?

[defumar]

~/MToDo/src$ gdb src
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) break main
Breakpoint 1 at 0x8048596: file main.cpp, line 5.
(gdb) run
Starting program: /home/defumar/MToDo/src/src
[Thread debugging using libthread_db enabled]
[New Thread -1224476992 (LWP 6527)]
[Switching to Thread -1224476992 (LWP 6527)]

Breakpoint 1, main (argc=1, argv=0xbf9218f4) at main.cpp:5
5 QApplication app(argc, argv);
(gdb) bt
#0 main (argc=1, argv=0xbf9218f4) at main.cpp:5
(gdb) n
Qt: gdb: -nograb added to command-line options.
Use the -dograb option to enforce grabbing.
7 return 0;
(gdb) bt
#0 main (argc=Cannot access memory at address 0x0
) at main.cpp:7
(gdb) p argc
Cannot access memory at address 0x0
(gdb) n
8 }
(gdb) bt
#0 main (argc=0, argv=0xa9) at main.cpp:8
(gdb) n
0xb73d3050 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
(gdb) n
Single stepping until exit from function __libc_start_main,
which has no line number information.

Program exited normally.

I am not sure whether the debugger messes up or the project itself, frankly I have no idea. Are there other debuggers I could try?

[wysota]

It's not the QApplication constructor that segfaults, look that something happens at line 7. argc changes from 1 to 0. Do examples bundles with Qt build and run correctly? Are you able to run any Qt4 based application?

[defumar]

The examples run fine. Perhaps I should ignore the error? I tried debugging one of the examples which also gave me the "argc=Cannot access memory at address 0x0". I guess it's, uh... normal?

[wysota]

Does it only happen when you debug? I think your gdb is invalid.

[defumar]

I think so as well. It only happens when I debug, yes.

Edit: aaargh, I downloaded gdb 6.7, compiled it, installed it, verified its version, tried to debug and yes, you can guess it alright. argc=cannot access mem at 0x0
So with a newer version it still acts weird... Might be some ubuntu issue still, I think.

[wysota]

gdb might only reveal the real problem which might be completely elsewhere. For instance in debug symbols of Qt or libc or some other library.

[Gopala Krishna]

Probably your qt build is corrupt i think. I closely looked at QApplication constructor and it uses
int reference for argc parameter. I dont know whether this is the problem or not but can you tell me where it crashes if you try the below program.


int main(int argc, char *argv[])
{
int k = argc + 1;
int l = argc;
QApplication app(argc, argv);
//also try QApplication(l, argv);
return 0;
}


Also pay attention to this qapplication doc

Initializes the window system and constructs an application object with argc command line arguments in argv.

Warning: The data pointed to by argc and argv must stay valid for the entire lifetime of the QApplication object.

The global qApp pointer refers to this application object. Only one application object should be created.

This application object must be constructed before any paint devices (including widgets, pixmaps, bitmaps etc.).

Note that argc and argv might be changed. Qt removes command line arguments that it recognizes. The original argc and argv can be accessed later with arguments().

[defumar]

okay I tried both things and both of them got corrupted after the QApplication ctor (both having argc=cannot access 0x0)

[wysota]

The problem is clearly within gdb. If it was your application that was crashing you'd receive a different message from the debugger. Look that the "cannot access 0x0" message is received while the debugger tries to print the content of argc and not when executing any code from your application. The application doesn't crash when you don't debug it, so there is nothing wrong with it. Your debugger doesn't like your Qt installation or it doesn't like itself or your system. Either way your application is correct.

[Gopala Krishna]

Oh i just can't believe this! Even gdb on my comp shows the same thing for any program i debug(wysota, i tried your chip program ;) )

And i use kubuntu. :)
Probably you are right wysota.

[wysota]

For the record - for me GDB works just fine ;)

[defumar]

okay, so I installed SUSE 10.3 and on this one I get argc=1 before executing the ctor and argc=4 after executing the ctor and before exitting the function, according to gdb, is this correct or am I haunted?

[wysota]

Could be. QApplication takes its arguments by reference, so it is likely that it modifies them.

[defumar]

goodie, thanks for all the help