search

mupen64plus / mupen64plus-user-issues

Issue reports from users go here
http://www.mupen64plus.org/
17 stars 3 forks source link

[Linux] [Legend of Zelda: OOT @ Sand Temple] Segmentation fault: Out of bound address #549

Open richard42 opened 9 years ago

richard42 commented 9 years ago

Originally reported on Google Code with ID 550

Arch Linux 64-bit
Latest richard42's repositories

Plugins used:
  RSP: HLE
  Video: Glide64mk2
  Input: SDL
  Audio: SDL

Problem Game: "Legend of Zelda: Ocarina of Time" (THE LEGEND OF ZELDA)

Texture Pack: Emutalk Community Pack (http://www.emutalk.net/threads/51481-Zelda-Ocarina-of-time-Community-Retexture-Project-V6-Development-Topic)

I recieve a segmentation fault in one of two places. When I compile Glide64mk2 with
optimization and no debug, I segfault after I've beaten the boss in the Sand Temple
(a small delay, not enough to let me save). I unfortunately can't provide much info
on this one specifically, see below.

When I compile without optimization and debug symbols, I segfault immediately when
I open the door to the Sand Temple boss. I've provided a save state that sits you in
front of the problem door. 

Using nemiver with gdb, I've narrowed it down to LoadTex (in Glide64/TexCache.cpp)
sending ext_ghq_checksum (in GlideHQ/Ext_TxFilter.cpp) an out of bounds address (passed
as src).

Also, here is a sample (no pun intended) line on how each object was compiled: 
g++ -fvisibility-inlines-hidden -std=gnu++0x  -Wall -ffast-math -fno-strict-aliasing
-fvisibility=hidden -I../../src -I../../src/Glitch64/inc -DGCC -mmmx -msse -fPIC  -I/usr/include/libpng16
 -I/usr/include/libdrm  -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/mupen64plus
-g -MD -D__unix__ -DTEXTURE_FILTER   -c -o _obj/GlideHQ/TxReSample.o ../../src/GlideHQ/TxReSample.cpp

Reported by admin@computerquip.com on 2013-05-19 21:54:30

richard42 commented 9 years ago 
Forgot to mention that it works without using a texture pack, but that's to be expected
I would think.

Reported by admin@computerquip.com on 2013-05-19 22:00:09

richard42 commented 9 years ago 
Please really provide a savestate (not a savegame) right before this happens (it is
ok when we have to do a minor action). But I am not willing to play through a whole
game to test a bug. Also provide the hashes (CRC32 and MD5 as shown by mupen64plus)
of the rom.

Am I right that this only happens when you have ghq_hires set to 1?

Reported by sven@narfation.org on 2013-05-20 07:32:43

richard42 commented 9 years ago 
Made attachment of savestate.

Reported by admin@computerquip.com on 2013-05-20 07:55:06

richard42 commented 9 years ago 
Some ROM info given by the emulator:

Goodname: Legend of Zelda, The - Ocarina of Time (U) (V1.0) [!]
Name: THE LEGEND OF ZELDA 
MD5: 5BD1FE107BF8106B2AB6650ABECD54D6
CRC: ec7011b7 7616d72b
Imagetype: .z64 (native)
Rom size: 33554432 bytes (or 32 Mb or 256 Megabits)
Version: 1449
Manufacturer: 43
Country: USA

Yes, ghq_hires must be set for the bug to happen.

Reported by admin@computerquip.com on 2013-05-20 07:58:32

richard42 commented 9 years ago 
I can confirm this problem on amd64. Thanks for the savestate.

A good way to compile glide64mk2 for a test is:

CFLAGS=-g3 make OPTFLAGS="" -C projects/unix all

Regarding the requirements of the texture pack.. you only need one dummy texture to
enable the crc stuff. I've attached one such dummy texture which has to be saved under

$HOME/.local/share/mupen64plus/hires_texture/THE LEGEND OF ZELDA/

Reported by sven@narfation.org on 2013-05-20 08:50:34

richard42 commented 9 years ago 
It seems to me that the address at rdp.addr[rdp.tiles[td].t_mem] aka rdp.addr[0] is
terrible big (2830748116; N64 didn't have 3 gig of ram ;) ) when LoadTex is called.

This weird address comes from loadBlock directly called before the next load 

Old value = 3432992
New value = 2830748116
loadBlock (src=0x7ffff6173700, dst=0x7fffeb0c0ec4, off=3432992, dxt=268435456, cnt=512)
at ../../src/Glide64/rdp.cpp:1886
1886            v5[1] = bswap32(v7[1]);
1: rdp.addr[0] = 2830748116
#0  loadBlock (src=0x7ffff6173700, dst=0x7fffeb0c0e84, off=3432992, dxt=268435456,
cnt=512) at ../../src/Glide64/rdp.cpp:1886
#1  0x00007fffe9dffa47 in rdp_loadblock () at ../../src/Glide64/rdp.cpp:2032
#2  0x00007fffe9dfa23e in ProcessDList () at ../../src/Glide64/rdp.cpp:815
#3  0x00007fffe667376e in DoRspCycles () from /usr/lib/x86_64-linux-gnu/mupen64plus/mupen64plus-rsp-hle.so
#4  0x00007ffff4ef838c in ?? () from /usr/lib/x86_64-linux-gnu/libmupen64plus.so.2
#5  0x00007ffff4ef55fd in ?? () from /usr/lib/x86_64-linux-gnu/libmupen64plus.so.2
#6  0x00007ffff4efea9d in CoreDoCommand () from /usr/lib/x86_64-linux-gnu/libmupen64plus.so.2
#7  0x0000555555557701 in main ()

As we can see, the problem is the writing outside the tmem (and therefore in the addr
memory).

I've attached a small debug patch to make it easier to reproduce this with revision
90:3a99cd5c5dd2

And just as note how to find the problem again, here is my gdb session:

$ gdb --args mupen64plus --gfx projects/unix/mupen64plus-video-glide64mk2.so ~/tmp/zelda.us
b LoadTex
r
delete 1
b ../../src/Glide64/rdp.cpp:1981
c
delete 1
display display rdp.addr[0]
watch rdp.addr[0]
c

Reported by sven@narfation.org on 2013-05-20 10:25:13

richard42 commented 9 years ago 
In this case, loadBlock got an offset with the lower bits not set -> so it jumps directly
to LABEL_23 (v5 is still relative to the start of tmem at byte 512). Now the big swapping
begins from (source address + offset_minus_lower_2_bit) (v7) to the target. And this
will be done v6 times (cnt). Each time 8 byte are copied. So 4096 bytes will be copied...
which seems to be impossible. The reason for this is the length of tmem (only 4096
bytes long). So it is overwriting 512 bytes after the tmem... and these are the addresses.

A quick patch I would came up is attached. Maybe someone with more rdp expertise can
better interpret this problem.

Reported by sven@narfation.org on 2013-05-20 10:54:56

richard42 commented 9 years ago 
Small correction: 2048 bytes will be overwritten after tmem. Accidentally did the multiplication
with 8 in my head, but the hands didn't want to follow the calculation ;)

Reported by sven@narfation.org on 2013-05-20 11:06:49

richard42 commented 9 years ago

Reported by sven@narfation.org on 2013-05-20 11:13:35