search

pilegod / mupen64plus

Automatically exported from code.google.com/p/mupen64plus
0 stars 0 forks source link

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

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
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

Original issue reported on code.google.com by ad...@computerquip.com on 19 May 2013 at 9:54

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

Original comment by ad...@computerquip.com on 19 May 2013 at 10:00

GoogleCodeExporter commented 8 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?

Original comment by s...@narfation.org on 20 May 2013 at 7:32

GoogleCodeExporter commented 8 years ago 
Made attachment of savestate.

Original comment by ad...@computerquip.com on 20 May 2013 at 7:55

Attachments:

GoogleCodeExporter commented 8 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.

Original comment by ad...@computerquip.com on 20 May 2013 at 7:58

GoogleCodeExporter commented 8 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/

Original comment by s...@narfation.org on 20 May 2013 at 8:50

Attachments:

GoogleCodeExporter commented 8 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

Original comment by s...@narfation.org on 20 May 2013 at 10:25

Attachments:

GoogleCodeExporter commented 8 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.

Original comment by s...@narfation.org on 20 May 2013 at 10:54

Attachments:

GoogleCodeExporter commented 8 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 ;)

Original comment by s...@narfation.org on 20 May 2013 at 11:06

GoogleCodeExporter commented 8 years ago

Original comment by s...@narfation.org on 20 May 2013 at 11:13