Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Debug problem in Dev-C++

This thread is locked; no one can reply to it. rss feed Print
Debug problem in Dev-C++
Vasco Freitas
Member #6,904
February 2006
avatar

When I try to debug from Dev-C++ (that uses GDB), a window pops up with this warning: "An Access Violation (Segmentation Fault) raised in your program.". What's strange is that, its seems that no code is executed, and if I go to backtrace nothing appears... The game compiles and runs without problems though. What could be causing this?

GullRaDriel
Member #3,861
September 2003
avatar

Dunno. Try in command line by launching your prog trough gdb.

Example:

C:\myprog\
C:\myprog\gdb myprog.exe
GNU gdb 6.3
Copyright 2004 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 "i686-pc-mingw32"...(no debugging symbols found)

(gdb) run (type here your arguments if any needed, example: run datafile.dat)

And see what happens.

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Vasco Freitas
Member #6,904
February 2006
avatar

OK, so here's what I got:

Program received signal SIGSEGV, Segmentation fault.
0x7c918fea in _libwinmm_a_iname ()
(gdb) backtrace
#0  0x7c918fea in _libwinmm_a_iname ()
#1  0x00000001 in ?? ()
#2  0x7c90104b in _libwinmm_a_iname ()
#3  0x77ddeb4d in _libwinmm_a_iname ()
#4  0x77dfd5f4 in _libwinmm_a_iname ()
#5  0x6650127a in _libuser32_a_iname ()
#6  0x7c9011a7 in _libwinmm_a_iname ()
#7  0x7c91cbab in _libwinmm_a_iname ()
#8  0x7c916178 in _libwinmm_a_iname ()
#9  0x7c9162da in _libwinmm_a_iname ()
#10 0x7c801bb9 in _libwinmm_a_iname ()
#11 0x7c80ae5c in _libwinmm_a_iname ()
#12 0x77d753a1 in _libwinmm_a_iname ()
#13 0x77d4a118 in _libwinmm_a_iname ()
#14 0x77d4a143 in _libwinmm_a_iname ()
#15 0x77d4f794 in _libwinmm_a_iname ()
#16 0x7c9011a7 in _libwinmm_a_iname ()
#17 0x7c91cbab in _libwinmm_a_iname ()
#18 0x7c92173e in _libwinmm_a_iname ()
#19 0x7c921639 in _libwinmm_a_iname ()
(gdb)

I saw that this problem has been discussed here, so I'll try static linking...

Arthur Kalliokoski
Second in Command
February 2005
avatar

If it's C++ program and you have global constructors, they could be doing it before you get to main(). I don't remember if gdb step through the startup code or not.

They all watch too much MSNBC... they get ideas.

BAF
Member #2,981
December 2002
avatar

I see that libwinmm_a_iname crap a LOT, not just in Allegro programs, and not in C++ either. I dont know what it is but it sure seems to crop up a lot (mostly when you have really messed up pointers or something).

Vasco Freitas
Member #6,904
February 2006
avatar

This problem is definitely related to allegro. The debugger works fine without allegro, but if I use gdb with this simple program:

#include <allegro.h>
int main() {
}
END_OF_MAIN();

The exact same error appears. The addresses in the backtrace are also the same (only difference from the other program is instead of "_libuser32_a_iname ()" it's "_libwinmm_a_iname ()").

:-/

GullRaDriel
Member #3,861
September 2003
avatar

You seem to compile under windows, You should add #include <winalleg.h> under #include <allegro.h>.

I think that your problem can also come from your version of gcc.

Please type gcc --v or g++ --v and give us the result.

If you are lower than 3.4.4, you should upgrade and retry.

I also found some threads related to your problem.

In these threads, I found one which sounds interstening:

Fabiano Lopez said:

This isn't fair... :D
It does NOT crash running the DEBUGMODE=2... ???
EDIT: It seems
-mtune=i686
causes the problem. I tried
-mtune=i586
(as replacement for
-mpentium
and it worked fine).

_

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Vasco Freitas
Member #6,904
February 2006
avatar

Thanks for your help, although nothing worked... :-/

The current version of MinGW gcc is 3.4.2, there's a Candidate version 3.4.5, but I couldn't get it to compile the game, it said it couldn't find some object file at the linking stage.

I compiled and installed allegro with DEBUGMODE=2 and that didn't work either.

I tried with gdb 5.2.1 (the one I used before) and gdb 6.3, they both give segmentation fault although the 6.3 version gave a different backtrace.

If anyone has more ideas please tell, in the meanwhile I'll try searching other threads...

GullRaDriel
Member #3,861
September 2003
avatar

Did you try recompiling allegro library with different -mtune settings ?

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

gnolam
Member #2,030
March 2002
avatar

Quote:

You seem to compile under windows, You should add #include <winalleg.h> under #include <allegro.h>.

No he shouldn't.

--
Move to the Democratic People's Republic of Vivendi Universal (formerly known as Sweden) - officially democracy- and privacy-free since 2008-06-18!

Vasco Freitas
Member #6,904
February 2006
avatar

GullRaDriel said:

Did you try recompiling allegro library with different -mtune settings ?

Yes I did that too, same problem...

gnolam said:

No he shouldn't.

I tried both ways...

GullRaDriel
Member #3,861
September 2003
avatar

Last try: did you link with debbuged version of allegro when testing ?

I have used all my bullets. Hope for you someone else will give a shot.

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Vasco Freitas
Member #6,904
February 2006
avatar

Yes, I've been linking with -alld. Thanks anyway, I'm going to double check everything I did to make sure I didn't miss anything...

GullRaDriel
Member #3,861
September 2003
avatar

A thing that could change things (why not) Which version of allegro are you using ?

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

CGamesPlay
Member #2,559
July 2002
avatar

I've had a friend with a similar Allegro debugging problem. Any Allegro program can't be debugged. I think we went so far as to compile Allegro from sources using a version of MinGW downloaded form the MinGW site, all to no avail. If I used MinGW, I might look mroe into it ;)

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

Vasco Freitas
Member #6,904
February 2006
avatar

I have version 4.2 of Allegro.

If anyone can use gdb with MinGW g++ could you please post your gdb, g++ and allegro versions, and any modifiers you used to compile allegro (like DEBUGMODE, mtune)? Thanks.

TeamTerradactyl
Member #7,733
September 2006
avatar

I use MinGW g++, as well as GDB and Allegro. My programs work fine (when I'm not making stupid mistakes):

<pre>G++: g++ (GCC) 3.2.3 (mingw special 20030504-1) GDB: GNU gdb 5.2.1 Allegro: Allegro 4.2.0 (beta4), released Jun 26, 2005 </pre>
I know; some are getting a little old. But why upgrade when what you've got works? Or is that the other way around..?

I usually compile with the following arguments:

<pre> g++ -ggdb3 -W -Wall prog1.cpp prog2.cpp ... -o binary.exe -lalld</pre>
Then run GDB with all my command-line arguments (if the program requires any) on the command-line:

<pre> gdb --args binary.exe arg1 arg2 "string for arg3" arg4 ...</pre>
Then inside GDB, simply run ("r") and backtrace where the problem occurs.

I could also ask whether or not you could post a snippit of your code that is failing?

-TeamTerradactyl

Vasco Freitas
Member #6,904
February 2006
avatar

TeamTerradactyl said:

I could also ask whether or not you could post a snippit of your code that is failing?

I did, it doesn't work with just:

#include <allegro.h>
int main() {
}
END_OF_MAIN();

When I ran g++ like you do, I got these messages, is this helpful?:

C:\Dev-Cpp\Projects\DebugTest2>g++ -ggdb3 -W -Wall DebugTest2.exe -lalld > test.
txt
DebugTest2.exe(.text+0x220):crtstuff.c: multiple definition of `mainCRTStartup'
C:/dev-cpp/bin/../lib/gcc/mingw32/3.4.2/../../../crt2.o(.text+0x220):crt1.c: fir
st defined here
DebugTest2.exe(.text+0x240):crtstuff.c: multiple definition of `WinMainCRTStartu
p'
C:/dev-cpp/bin/../lib/gcc/mingw32/3.4.2/../../../crt2.o(.text+0x240):crt1.c: fir
st defined here
DebugTest2.exe(.text+0x260):crtstuff.c: multiple definition of `atexit'
C:/dev-cpp/bin/../lib/gcc/mingw32/3.4.2/../../../crt2.o(.text+0x260):crt1.c: fir
st defined here
DebugTest2.exe(.text+0x270):crtstuff.c: multiple definition of `_onexit'
C:/dev-cpp/bin/../lib/gcc/mingw32/3.4.2/../../../crt2.o(.text+0x270):crt1.c: fir
st defined here
DebugTest2.exe(.text+0x280):crtstuff.c: multiple definition of `__do_sjlj_init'
C:/dev-cpp/bin/../lib/gcc/mingw32/3.4.2/crtbegin.o(.text+0x0):crtstuff.c: first
defined here
DebugTest2.exe(.bss+0x4): In function `WinMain':
C:/Dev-Cpp/Projects/DebugTest2/main.cpp:6: multiple definition of `_argc'
C:/dev-cpp/bin/../lib/gcc/mingw32/3.4.2/../../../crt2.o(.bss+0x4):crt1.c: first
defined here
DebugTest2.exe(.bss+0x0): In function `WinMain':
C:/Dev-Cpp/Projects/DebugTest2/main.cpp:6: multiple definition of `_argv'
C:/dev-cpp/bin/../lib/gcc/mingw32/3.4.2/../../../crt2.o(.bss+0x0):crt1.c: first
defined here
collect2: ld returned 1 exit status

Arthur Kalliokoski
Second in Command
February 2005
avatar

You must have more than one module with "main()" in it? There's one and only one main() in an entire program. The other modules simply have functions that are called by main().

and END_OF_MAIN() shouldn't have a semicolon after it.

They all watch too much MSNBC... they get ideas.

Vasco Freitas
Member #6,904
February 2006
avatar

Arthur Kalliokoski said:

You must have more than one module with "main()" in it?

I sure didn't make more than one "main()"... And allegro library shoudn't have any. Otherwise, it wouldn't even compile.

Arthur Kalliokoski said:

and END_OF_MAIN() shouldn't have a semicolon after it.

Without the semicolon the result is the same.

Go to: