Restructure update

**AnonymousHero** · February 19, 2015, 16:32

Originally posted by Nick

ssize_t is not C standard (it's POSIX standard), so we should be using int. get.c and get.h are not included in the standard buildsystem build, and will probably go from the codebase altogether.

I would suggest using typedefs on WINDOWS instead. (OK, ssize_t is a bit weird, but for uint8_t, etc. I would still suggest typedefs and using typedefs only on WINDOWS.)

Also, about the pointer bits: See my post about -fsanitize. (Will require a semi-recent GCC/Clang, i.e. something released in the last two years, or thereabouts.)

**Nick** · February 19, 2015, 21:42

Originally posted by AnonymousHero

What you want for practical applications is to just add

-fsanitize=undefined
-fsanitize=address

to the clang/gcc command line. It's runtime checking, but the fact that it only points out real errors that you actually hit in the game means that it's actually humanly possible to actually fix all the issues.

Thanks, I had actually seen this in the PosCheng thread and looked into it a little.

The main issue with Windows is just that we don't have any of the dev team compiling on it routinely at the moment, and our autobuilders are nearly all Linux too. On the plus side, the one that isn't is OpenBSD...

**chris** · February 19, 2015, 21:57

Originally posted by AnonymousHero

What you want for practical applications is to just add

-fsanitize=undefined
-fsanitize=address

to the clang/gcc command line. It's runtime checking, but the fact that it only points out real errors that you actually hit in the game means that it's actually humanly possible to actually fix all the issues.

My gcc does not recognize -fsanitize=undefined? (gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2)

Also, the output is hideous:

Code:

                                                        #3 0x5a57af (/home/chris/Src/poschengband/poschengband+0x5a57af)
                                                                                                                            #4 0x5a904a (/home/chris/Src/poschengband/poschengband+0x5a904a)
                          #5 0x9ed773 (/home/chris/Src/poschengband/poschengband+0x9ed773)
                                                                                              #6 0x7fb93812cec4 (/lib/x86_64-linux-gnu/libc-2.19.so+0x21ec4)
                                                                                                                                                                #7 0x403828 (/home/chris/Src/poschengband/poschengband+0x403828)
                                                          Address 0x7fff0742c4e1 is located at offset 113 in frame <Term_text_gcu> of T0's stack:
You see no visible monsters.                                                                                                                       This frame has 1 object(s): a granite wall blocking your way. <x2>
You have    [32, 113) 'text'.
The Blinking dot blinks awayHINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
Autosaving the game...                                                                                                                     (longjmp and C++ exceptions *are* supported)e surface.
Target Aborted.  Shadow bytes around the buggy address:
                                                         0x100060e7d840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                                                                                                                          0x100060e7d850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                     0x100060e7d860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                                                                                      0x100060e7d870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                                                                                                                                                       0x100060e7d880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
                                                =>0x100060e7d890: f1 f1 00 00 00 00 00 00 00 00 00 00[01]f4 00 00
                                                                                                                   0x100060e7d8a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
              0x100060e7d8b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                                                                               0x100060e7d8c0: 00 00 00 00 f1 f1 f1 f1 01 f4 f4 f4 f2 f2 f2 f2
                                                                                                                                                0x100060e7d8d0: 01 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
                                           0x100060e7d8e0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
                                                                                                          Shadow byte legend (one shadow byte represents 8 application bytes):
          Addressable:           00
                                     Partially addressable: 01 02 03 04 05 06 07 
                                                                                   Heap left redzone:     fa
                                                                                                              Heap righ redzone:     fb
                                                                                                                                         Freed Heap region:     fd
                                                                                                                                                                    Stack left redzone:    f1
                         Stack mid redzone:     f2
                                                    Stack right redzone:   f3
                                                                               Stack partial redzone: f4
                                                                                                          Stack after return:    f5
                                                                                                                                     Stack use after scope: f8
                                                                                                                                                                Global redzone:        f9
                     Global init order:     f6
                                                Poisoned by user:      f7
                                                                           ASan internal:         fe
                                                                                                    ==4654== ABORTING
                                                                                                                     chris@chris-Studio-XPS-1645:~/Src/poschengband >

Any way to clean this up? For my particular issue, simply doing a bt in gdb is much easier, but I have to turn off the -fsanitize=address to actually get a stack dump:

Code:

    *** stack smashing detected ***: /home/chris/Src/poschengband/poschengband terminated

Program received signal SIGABRT, Aborted.
0x00007ffff72c9cc9 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff72c9cc9 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff72cd0d8 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff7306f24 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff739e82c in __fortify_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007ffff739e7d0 in __stack_chk_fail () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x0000000000672ac1 in Term_text_gcu (x=13, y=48, n=99, a=15 '\017', s=0xa2918d '#' <repeats 99 times>, ' ' <repeats 101 times>...) at main-gcu.c:1125
#6  0x0000000000676069 in Term_fresh_row_text (y=48, x1=0, x2=145) at z-term.c:1052
#7  0x0000000000676804 in Term_fresh () at z-term.c:1422
#8  0x00000000004c1d94 in dungeon (load_game=1 '\001') at dungeon.c:5281
#9  0x00000000004c3535 in play_game (new_game=0 '\000') at dungeon.c:6034
#10 0x000000000067974f in main (argc=1, argv=0x7fffffffdde8) at main.c:779
(gdb)

Help?

**AnonymousHero** · February 19, 2015, 22:59

(On a tablet, so forgive the brevity)

Output: there may be an option or env variable you can set to force sanitizer output to a file. If not, I'm pretty sure you can just redirect stderr to a file, eg using "2>1 myfile" as the last part of the command line. (The reason the output is mangled is that ncurses disables newlines on the terminal.)

About the missing "undefined": see the gcc manual, i was workingfrom memory and the option may be a little different, something to do with "undefined behavior". It's possible that the option wasn't available in gcc 4.8.

Generally i'd recommend clang when using the sanitizer since it usually has more recent support. (And is mostly cmdline compatible with gcc.)

EDIT: Sorry, "2>&1 myfile" should obviously have been "2> myfile". Fixed

**TJS** · February 20, 2015, 00:08

Originally posted by Nick

Thanks for picking up all these - I will get to fixing them at some point, but this should keep you going for now.

Great thanks, that's now got me onto the linker errors

I went through the other thread and fixed the linker errors that appeared on there, and changed the names of some functions that were deprecated as recommended:

open to _open
fdopen tp _fdopen
my_mkdir to _mkdir

but I've still got a few linker errors

Error 1 error LNK2019: unresolved external symbol __fopen referenced in function _file_open angband-latest\z-file.obj
Error 2 error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup angband-latest\MSVCRTD.lib(crtexew.obj)

**AnonymousHero** · February 20, 2015, 06:34

Originally posted by TJS

Great thanks, that's now got me onto the linker errors

I went through the other thread and fixed the linker errors that appeared on there, and changed the names of some functions that were deprecated as recommended:

open to _open
fdopen tp _fdopen
my_mkdir to _mkdir

Do you mean that you've renamed "open" to "_open" in the .h and .c files? If so, then you've been given bad advice since the C standard reserves all "external" identifiers beginning with an underscore. If you've renamed the other way round, then I'd like to point out that "open" (specifically) is also already taken by POSIX and, as such, your changes could not be accepted upstream (if you're interested in providing pull req's once you get things compiling and running

)

**EpicMan** · February 20, 2015, 19:49

Originally posted by TJS

Great thanks, that's now got me onto the linker errors

I went through the other thread and fixed the linker errors that appeared on there, and changed the names of some functions that were deprecated as recommended:

open to _open
fdopen tp _fdopen
my_mkdir to _mkdir

but I've still got a few linker errors

Error 1 error LNK2019: unresolved external symbol __fopen referenced in function _file_open angband-latest\z-file.obj
Error 2 error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup angband-latest\MSVCRTD.lib(crtexew.obj)

Error 1 looks like a typo - it looks like you have two underscores in front of fopen. Try changing it to _fopen and see if it works.

**TJS** · February 23, 2015, 15:14

Ok I've managed to get a title screen! Thanks for the help. However the problems documented in this post are still happening in the current version:

Getting Angband from Github and compiling it - Angband Forums

http://angband.oook.cz/forum/showpost.php?p=89382&postcount=100

Code wrangling and compiling talk

It seems to default to graphical tiles and then screw up in the png_read_info(png_ptr, info_ptr); method.

I can get the game running by changing this line to skip the ReadDIB2_PNG function that crashes:

if (FALSE) { // !ReadDIB2_PNG(data[0].w, buf, &infGraph, NULL, TRUE)) {
plog_fmt("Cannot read file '%s'", name);
return FALSE;
}
The game seems to run, but obviously I've commented out the graphics so you can't see any tiles (is there a way to default to ASCII?).

Also looks like the look rectangle isn't getting deleted when you move it around.

**Nick** · February 23, 2015, 20:44

Originally posted by TJS

Ok I've managed to get a title screen! Thanks for the help. However the problems documented in this post are still happening in the current version:

Getting Angband from Github and compiling it - Angband Forums

http://angband.oook.cz/forum/showpost.php?p=89382&postcount=100

Code wrangling and compiling talk

Have you tried the changes to VS settings mentioned later in that thread?

**TJS** · February 23, 2015, 21:40

Originally posted by Nick

Have you tried the changes to VS settings mentioned later in that thread?

Whoops sorry I suck, I read that whole thread and missed the fix from EpicMan, I've updated the above post to remove stuff that is fixed and left the stuff that's still broken.

**Nick** · February 23, 2015, 23:02

This is looking to me like a problem with the png libraries - do you have libpng12.dll in your top level directory when you're running the game?

**TJS** · February 24, 2015, 10:50

Originally posted by Nick

This is looking to me like a problem with the png libraries - do you have libpng12.dll in your top level directory when you're running the game?

Yes it is definitely there already and the program won't even compile if I rename it. I've also added the libpng.lib to the path as well which it needs to run (should this be libpng12.lib?).

Maybe the latest VS needs a newer version of the library or something.

It crashes when calling png_read_info(png_ptr, info_ptr); in readpng.c

Commenting that line out allows the program to run, but you don't see any in game tiles.

**Nick** · February 24, 2015, 11:32

OK, this seems to be pretty much what you're experiencing (C++, but whatever) - maybe try some of the suggestions there.

Are you getting menus now, and can you change to ASCII or different graphics? If so, do any graphics modes work, and if so which?

**TJS** · February 25, 2015, 13:18

Originally posted by Nick

OK, this seems to be pretty much what you're experiencing (C++, but whatever) - maybe try some of the suggestions there.

Are you getting menus now, and can you change to ASCII or different graphics? If so, do any graphics modes work, and if so which?

Thanks for the information. I implemented the suggestions and it gets a little bit further before crashing now.

After calling png_read_info(png_ptr, info_ptr); it crashes in this method:

bool file_exists(const char *fname)
{
struct stat st;
return (stat(fname, &st) == 0);
}

With fname containing this:

fname = 0x00000001 <Error reading characters of string.>

The other menus and fonts are working now, I can play the game by commenting out the graphics code and then changing to ASCII graphics by selecting Graphics->None

Starting in ASCII and changing to any other tileset except Shockbolt crashes here:

Unhandled exception at 0x7794E193 (ntdll.dll) in angband-latest.exe: 0xC0000005: Access violation writing location 0x00000014.

In main-win.c Line 1712:
DispatchMessage(&msg);

Whereas changing to Shockbolt still crashes in the file_exists method.

**Nick** · February 25, 2015, 13:42

Originally posted by TJS

After calling png_read_info(png_ptr, info_ptr); it crashes in this method:

Code:

bool file_exists(const char *fname)
{
struct stat st;
return (stat(fname, &st) == 0);
}

With fname containing this:

Code:

fname = 0x00000001 <Error reading characters of string.>

This looks like file_exists is being passed a null pointer. Can you determine which occurrence of file_exists it is crashing in? There are several; one of the ones in main-win.c seems most likely.