How to debug linux crashes

[Whistler]

try http://gcc.gnu.org

[The Storm]

I don't understand very much from GCC but I don't think that in http://gcc.gnu.org will be explained the special GCC-Cygwin flags.

[KWo]

If someone is interrested , I found the link to the flags description.
http://gcc.gnu.org/onlinedocs/gcc/Op...Option-Summary

[KWo]

Currently drmngw says:

Originally Posted by drmingw

hlds.exe caused an Access Violation at location 077aa5e1 in module podbot_mm.dll Reading from location 0000017c.

Registers:
eax=00000174 ebx=0012f274 ecx=04b394e8 edx=0012f274 esi=012c014c edi=00000000
eip=077aa5e1 esp=0012f244 ebp=0012f25c iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206

Call stack:
077AA5E1 podbot_mm.dll:077AA5E1 GetEngineFunctions
07799E04 podbot_mm.dll:07799E04 GetEngineFunctions
077731CB podbot_mm.dll:077731CB
07785EAE podbot_mm.dll:07785EAE
07795BF4 podbot_mm.dll:07795BF4 GiveFnptrsToDll
6B234EAE metamod.dll:6B234EAE zone_shelter

It happens only when I'm using mingw for compilation. When I compile with M$ VC++ 2005 Express, seeems - it doesn't want to crash. Any idea?

[Whistler]

the information which Dr.MinGW gives is still incorrect. Normally it should give the exact code snippit of the crashing place.

About the MSVC: that's normal. When I was using MSVC6 and testing a very early version of YaPB it crashes when compiled with MSVC6, but doesn't crash if I compiled with Borland compiler. Later I found that it's a bug in the POD-Bot code (with the bot_sounds.cpp).

[KWo]

It has to be incorrect because drmingw should see somewhere the place of compiled *.o files or anything produced during compilation process to get some additional info which can't be only in binary *dll or *so. Also MSVC needs something more to make a good debug (some *pdb or *lib file produced during compilation). What exactly drmingw needs to show the line number of code where it crashes? I saw on some Fonseca'a page his drmingw should show the line number and file number (for example dll.cpp line112) - but I couldn't find nowhere what exactly this debugger needs to take this info. I believe -g3 parameter for compilation isn't only one thing drmingw needs.
Anyway - maybe You remember what exactly did You need to change in Your bot_sounds.cpp to get it working correctly with mingw?
Maybe at least show me which mistakes / errors in code M$VC can "forgive" but mingw doesn't?

When I compile with M$ Visual C++ 2005 Express it says some warnings like use _CRT_NO_DEPRECATE to prevent some warnings and it tryes to replace some C++ commands which it says might to be unsafe by some better one. Also it says some ARRAYSIZE is defined twice - once in some metamod (or HLSDK) *.h file and second time in winnt.h (M$ Platform SDK).

What currently the GCC version is recommended to use with HLSDK prepared by metamod dev team (HLSDK 2.3 p3)?
I'm using 3.4.2 (which AMX dev team is using a long time without any problem).

[Whistler]

if you compiled with -ggdb3 or -g3 it will be "integrated" into the dll or exe file. Make sure you do _not_ have "-s" parameter when linking.

[Whistler]

also afaik the file "MinGW-3.1.0.exe" from the MinGW web site works the best with HLSDK.

There are also some easier IDEs like Dev-C++ which you can use to avoid dealing with parameters.

"Maybe at least show me which mistakes / errors in code M$VC can "forgive" but mingw doesn't?"
well I was talking about an error which MSVC doesn't "forgive" but Borland C++ Builder "forgives" the error is something like this:

int a[5];
a[8] = 3; // 8 is larger than 5

normally the C/C++ won't generate errors on this if the a[8] area is a free memory area, but if the a[8] is used by other codes or programs it will crash. And different compilers may choose to use different memory areas, I think that's why it may "work" with this compiler but not that one.

[KWo]

Well - in my makefile there is "-s" parameter for linking. I provided all makefile I use few posts before (exactly here), to show You if everything is correct, and You said "seems OK".

Originally Posted by makefile by KWo

LINK_LINUX=$(CC_LINUX) $(CFLAGS) -shared -ldl -lm -static-libgcc $(OBJ_LINUX) $(EXTRA_LIBDIRS_LINUX) $(EXTRA_LIBS_LINUX) -s -o $@
LINK_WIN32=$(CC_WIN32) -mdll -Xlinker --add-stdcall-alias $(OBJ_WIN32) $(RES_OBJ_WIN32) $(EXTRA_LIBDIRS_WIN32) $(EXTRA_LIBS_WIN32) -s -o $@

OK - I'll try to remove it and compile again. Then we will see if it will say something more.

[Whistler]

well I didn't read that carefully and just checked the "-g" or "-ggdb"

sorry for the confusion