mac crash dumps

Discuss the future of Warzone 2100 with us.
-Kosh-
Trained
Trained
Posts: 203
Joined: 16 Sep 2009, 23:34

mac crash dumps

Post by -Kosh- »

I asked this before but I do not think I have received a answer.

Looking at this ticket http://developer.wz2100.net/ticket/950 why is it so vastly different than what is on the other platforms?

I saw in the code

Code: Select all

#if defined(WZ_OS_UNIX) && !defined(WZ_OS_MAC)
in the exceptionhandler.c file and just wondered why? Does it not work correctly or does it not compile correctly or just what is the problem?
Zarel, have you tried to change !defined(WZ_OS_MAC) to defined(WZ_OS_MAC) for testing?
This is a waste of space. Something important should be here.
User avatar
Zarel
Elite
Elite
Posts: 5770
Joined: 03 Jan 2008, 23:35
Location: Minnesota, USA

Re: mac crash dumps

Post by Zarel »

No, Apple just uses its own exception handler.
-Kosh-
Trained
Trained
Posts: 203
Joined: 16 Sep 2009, 23:34

Re: mac crash dumps

Post by -Kosh- »

Zarel wrote:No, Apple just uses its own exception handler.
Oh good, you fixed that ticket.

Code: Select all

Thread 0:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib             	0x9397b912 __kill + 10
1   libSystem.B.dylib             	0x9397b904 kill$UNIX2003 + 32
2   libSystem.B.dylib             	0x93a0eb99 raise + 26
3   libSystem.B.dylib             	0x93980b9b _sigtramp + 43
4   ???                           	0xffffffff 0 + 4294967295
5   net.wz2100.Warzone            	0x000450ca actionUpdateDroid + 9899
6   net.wz2100.Warzone            	0x00074f70 droidUpdate + 209
7   net.wz2100.Warzone            	0x000b8f5c gameLoop + 912
8   net.wz2100.Warzone            	0x000ba308 mainLoop + 362
9   net.wz2100.Warzone            	0x000baf63 SDL_main + 2548
Do you know what the offset is for? I see it crashes in actionUpdateDroid , but what does +9899 refer to? It can not be line number, so Image
This is a waste of space. Something important should be here.
User avatar
Zarel
Elite
Elite
Posts: 5770
Joined: 03 Jan 2008, 23:35
Location: Minnesota, USA

Re: mac crash dumps

Post by Zarel »

+9899 bytes? That's my guess. :S
-Kosh-
Trained
Trained
Posts: 203
Joined: 16 Sep 2009, 23:34

Re: mac crash dumps

Post by -Kosh- »

Zarel wrote:+9899 bytes? That's my guess. :S
I guess it is.

Mac dumps are useless as they are now.
To get any real results you must do this
put your release build and your .dSYM file in the same directory and use GDB to get symbolic information for numeric addresses.
Zarel, can you make a new test build and do this
the Xcode build setting reference tells us how to configure this. Or so one would think. Well, at least the relevant build settings are found in the environment variables … after you’ve written your shell script. The Xcode build transcript normally doesn’t show environment variables, but you can add a run script build phase to your target and check the option “Show environment variables in build log”. The environment variables reveal the default values for DWARF_DSYM_FOLDER_PATH and DWARF_DSYM_FILE_NAME, which Xcode uses in creating the dSYM file. Although you won’t find them in the target’s list of build settings, you can create them yourself in the User-Defined section. To embed the dSYM within the app bundle, just set DWARF_DSYM_FOLDER_PATH to $(CONFIGURATION_BUILD_DIR)/$(EXECUTABLE_FOLDER_PATH) and DWARF_DSYM_FILE_NAME to $(EXECUTABLE_NAME).dSYM. These settings should work for both apps and frameworks.
I hope that will get better crash dumps for macs unless you want to update each crash dump in the tracker with the gdb output after converting it?
This is a waste of space. Something important should be here.
User avatar
Zarel
Elite
Elite
Posts: 5770
Joined: 03 Jan 2008, 23:35
Location: Minnesota, USA

Re: mac crash dumps

Post by Zarel »

Hrm. We've apparently been stripping the release binaries for some reason. I just committed r8175, which should fix that.
-Kosh-
Trained
Trained
Posts: 203
Joined: 16 Sep 2009, 23:34

Re: mac crash dumps

Post by -Kosh- »

Zarel wrote:Hrm. We've apparently been stripping the release binaries for some reason. I just committed r8175, which should fix that.
lol

I was about to say it is better with this ticket since it shows the line numbers, then I thought, they must strip the builds!
http://developer.wz2100.net/ticket/952 since that looks like a self compiled version.
This is a waste of space. Something important should be here.