chocolate_duke3D icon indicating copy to clipboard operation
chocolate_duke3D copied to clipboard

segmentation fault in vlineasm4

Open gawen opened this issue 10 years ago • 4 comments

Hey there,

After compiling the project and putting my DUKE3D.GRP, I start the executable. The duke animation logo appears and finishes. Then a wild segmentation fault appears.

I recompile with debug options and start GDB.

$ gdb ./chocolate-duke3d 
...
(gdb) r
Starting program: chocolate-duke3d 
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
*** Chocolate DukeNukem3D v1.0 ***

Scanning directory './' for a GRP file like 'duke3d*.grp'.
Loading DUKE3D.GRP ...
GRP identified as: FULL 1.3D     
Commands: 
SDL display driver for the BUILD engine initializing.
  sdl_driver.c by Ryan C. Gordon ([email protected]).
Compiled Jun 30 2014 against SDL version 1.2.14 ...
Linked SDL version is 1.2.14 ...
Using SDL video driver "x11".Video Driver: 'x11'.
Using Setup file: 'duke3d.cfg'
CONFIG_ReadSetup...
STUB: CONTROL_ClearAssignments (CONTROL_ClearAssignments, control.c:471)
Compiling: 'GAME.CON'.
Including: 'DEFS.CON'.
Including: 'USER.CON'.
Code Size:48520 bytes(1425 labels).
Con version: Looks like v13
Initializing SDL joystick subsystem... (export environment variable BUILD_SDLJOYSTICK=none to skip)
SDL sees 2 joysticks.
Stick #0: [VirtualBox USB Tablet]
Stick #1: [VirtualBox mouse integration]
Using Stick #0.Set BUILD_SDLJOYSTICK to one of the above names to change.
Joystick initialized. 2 axes, 5 buttons, 0 hats, 0 balls.
Loading art header.
Art files loaded
Checking sound inits.
[New Thread 0x7ffff0ca8700 (LWP 18453)]
there is no soundcard
Checking music inits.
loadtmb()
RTS Manager Started.
Loading palette/lookups.
Highest physical resolution is (4480x1440).
Setting resolution ceiling to (1600x1200).
Final sorted modelist: (320x200) (640x350) (640x480) (800x600) (1024x768)screen surface is (640x480x8bpp).
New vidmode flags: SDL_HWPALETTE.
init_new_res_vars 640 480
genspriteremaps()

Program received signal SIGSEGV, Segmentation fault.
0x00000000004a55e3 in vlineasm4 (columnIndex=480, framebuffer=117898256) at draw.c:423
423                 temp = (((uint8_t *)(bufplce[i]))[temp]);

Stacktrace

(gdb) bt
#0  0x00000000004a55e3 in vlineasm4 (columnIndex=480, framebuffer=117898256) at draw.c:423
#1  0x00000000004b5573 in dorotatesprite (sx=32768, sy=32808, z=157286, a=0, picnum=2492, dashade=0 '\000', dapalnum=0 '\000', dastat=90 'Z', cx1=0, cy1=0, cx2=639, cy2=479) at engine.c:4059
#2  0x00000000004c6245 in rotatesprite (sx=0, sy=0, z=65536, a=0, picnum=2492, dashade=0 '\000', dapalnum=0 '\000', dastat=90 'Z', cx1=0, cy1=0, cx2=639, cy2=479) at engine.c:8061
#3  0x000000000042151b in Logo () at game.c:7542
#4  0x0000000000423340 in main (argc=1, argv=0x7fffffffe428) at game.c:8421

Variables

(gdb) info locals
i = 0
temp = 0
index = 118205456
dest = 0xfffffffffffb5000 <Address 0xfffffffffffb5000 out of bounds>
(gdb) info args
columnIndex = 480
framebuffer = 117898256
(gdb) p bufplce
$1 = {-249180332, -249180332, -249180132, -249180132}
(gdb) p ((uint8_t *)(bufplce[i]))[temp]
Cannot access memory at address 0xfffffffff125cf54

Threads

(gdb) info threads
  Id   Target Id         Frame 
  2    Thread 0x7ffff0ca8700 (LWP 18453) "chocolate-duke3" 0x00007ffff7606a43 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
* 1    Thread 0x7ffff7fd7700 (LWP 18449) "chocolate-duke3" 0x00000000004a55e3 in vlineasm4 (columnIndex=480, framebuffer=117898256) at draw.c:423

gawen avatar Jun 30 '14 15:06 gawen

Looks like you are building in 64bits. If you look at all the drawing routines you will see that pointers are passed at long (32bits). Try to compile in 32bits mode.

fabiensanglard avatar Jun 30 '14 15:06 fabiensanglard

Right. I cannot test right now but without any doubt this is the problem.

Thanks @fabiensanglard.

gawen avatar Jun 30 '14 15:06 gawen

The issue is still valid. The Makefile used to build 32bits by default but more and more systems are 64bits. We should update the makefile with a gcc parameter instructing we want a 32bits executable

fabiensanglard avatar Jun 30 '14 15:06 fabiensanglard

This particular issue is now resolved after merging PR #23.

rohit-n avatar May 03 '15 02:05 rohit-n