Opened 17 years ago

Closed 17 years ago

Last modified 7 months ago

#206 closed defect

Tru64 runtime error

Reported by: SF/e8cal1 Owned by: SF/bbrox
Priority: normal Component: Ports
Keywords: Cc:


Ver: ScummVM CVS snapshot 20020430 and 20020501 (no
others tested)
OS: Compaq Tru64 V4.0 (Alpha)
Compiler: Compaq C++ V6.3 and g++ 2.95.2 (both tested)

This is tested against SDL 1.2.0 (confirmed working
with other apps).

scummvm crashes when you try to start it:

> ./scummvm
Unable to open configuration file:

ScummVM - Scumm Interpreter
scummvm [-v] [-d[<num>]] [-n] [-b<num>]
[-t<num>] [-s<num>] [-p<path>] [-m<num>] [-f] game
-v - show version info and exit
-c<num> - use cdrom <num> for cd audio
-d[<num>] - enable debug output (debug level
-n - no subtitles for speech
-b<num> - start in room <num>
-t<num> - set music tempo (suggested:
-p<path> - look for game in <path>
-m<num> - set music volume to <num> (0-100)
-s<num> - set sfx volume to <num> (0-255)
-e<mode> - set music engine (see readme.txt
for details)
-r - emulate roland mt32 instruments
-f - fullscreen mode
-g<mode> - graphics mode
-a - specify game is amiga version
-w[<file>] - write to config file
-l<file> - load config file instead of
Error: Freeing invalid block.!

> ./scummvm -v
Unable to open configuration file:

Error: Freeing invalid block.!

/Anders Lindström

Ticket imported from: #550946. Ticket imported from: bugs/206.

Change History (18)

comment:1 Changed 17 years ago by SF/ender

This sounds like an intresting bug with the memory
allocation on 64 bit machines - I don't believe anyone has
tried it on one before...

And unfortunatly I don't really have one handy. I might be
able to get some time on the sourceforge compile cluster to
debug this, but I'm not sure.

comment:2 Changed 17 years ago by SF/e8cal1

Are you using the Sint64/Uint64 datatypes from SDL?

comment:3 Changed 17 years ago by SF/e8cal1

With CVS from 20020502 the "Freeing invalid block" error is gone. But scummvm now crashes when loading an

./scummvm monkey2
Unable to open configuration file: /users/etek/e98/e8cal1/.scummvmrc.

Detected game 'Monkey Island 2: LeChuck's revenge', version 5.2.2
WARNING: No path was provided. Assuming the data files are in the current direc$WARNING: Couldn't open
drive: Invalid CD-ROM drive index
WARNING: Sound initialization failed!
WARNING: Adlib music was selected, switching to midi null driver!
WARNING: Music not enabled - MIDI support selected with no MIDI driver availabl
Error(0:0:0x0): Bad ID RNAM found in directory!!

These files (monkey2) works with Linux.

comment:4 Changed 17 years ago by SF/bbrox

Did you try enabling in scummsys.h the following line :


Just after the test on the SDL byte order. This is in the
case the Alpha is booting in Little Endian mode but needs
aligned memory accesses.

comment:5 Changed 17 years ago by SF/bbrox

Owner: set to SF/bbrox

comment:6 Changed 17 years ago by SF/e8cal1

Didn't work.
cxx gives the same error and with g++ I get:
Error(0:0:0x0): Bad ID !

Anyway, I can use my Linux box to play scummvm, but please tell me if you want to test anything else to get
scummvm working with Tru64/64bit CPUs.

comment:7 Changed 17 years ago by SF/bbrox

Anyway, I think it cannot hurt :-)

Anyway, what would be nice would be for you to add the
following in, for example, main (in main.cpp) :

printf("%d %d %d %d %d %d %d %d\n", byte, uint8, uint16,
uint32, uint, int8, in16, int32);

And paste here the result.

comment:8 Changed 17 years ago by SF/e8cal1

byte 1
uint8 1
uint16 2
uint32 8 <=
uint 4
int8 1
int16 2
int32 8 <=

and all pointers are 64bit.

I think the correct typedefs (for all systems??) are:
typedef unsigned char uint8;
typedef signed char int8;
typedef unsigned short uint16;
typedef signed short int16;
typedef unsigned int uint32;
typedef signed int int32;

and to be failsafe (from SDL):
#define COMPILE_TIME_ASSERT(name, x) \
typedef int _dummy_ ## name[(x) * 2 - 1]
COMPILE_TIME_ASSERT(uint8, sizeof(Uint8) == 1);
COMPILE_TIME_ASSERT(int8, sizeof(Sint8) == 1);
COMPILE_TIME_ASSERT(uint16, sizeof(Uint16) == 2);
COMPILE_TIME_ASSERT(int16, sizeof(Sint16) == 2);
COMPILE_TIME_ASSERT(uint32, sizeof(Uint32) == 4);
COMPILE_TIME_ASSERT(int32, sizeof(Sint32) == 4);

But now it segfaults at startup:

thread 0x7 signal Segmentation fault at >*[strlen, 0x3ff8019eec0] ldq_u r1, 0(r16)
(dbx) where
> 0 strlen(0x3ffc0094bd0, 0x120029998, 0x120029b80, 0x140015538, 0x0) [0x3ff8019eec0]
1 SDL_WM_SetCaption(title = 0x4002da60, icon = 0x4002da60) ["SDL_video.c":1526, 0x3ffbffe3540]
2 property__11OSystem_SDLXiUi(this = 0x14002d580, param = 2, value = 1073928800) ["sdl.cpp":923,
3 main(argc = 2, argv = 0x11ffff6c8) ["main.cpp":116, 0x12008b464]

Strange... The window (and title) did show briefly before changing the data types.

Anyway, after I hacked that line we're back with:
Error(0:0:0x0): Bad ID RNAM found in directory!!

comment:9 Changed 17 years ago by SF/bbrox

Could you add in ressource.cpp at line 264 (ie before the
switch), a print like this :

printf("%08x %08x\n", blocktype, MKID('RNAM'));

By the way, is the Alpha little of big endian on True64 ?
Did you upgrade your CVS version recently (as I added a
run-time check for the endianness and alignement requirements) ?

As for the 'strlen' crash it comes from the crappy way
'set_property' is implemented :-) Will see tomorrow what I
can do for you.

comment:10 Changed 17 years ago by SF/bbrox

Well, with the latest CVS, the WM_SetCaption call should not
crash anymore so you should uncomment this line.

For the rest, waiting for the results of the printfs :-)

comment:11 Changed 17 years ago by SF/e8cal1

Alpha (Tru64) is little endian so that shouldn't be a problem.

What about the long => int thing in the datatypes typedefs? Isn't that how SDL does it?

I will test the latest CVS after the weekend and get back to you about the rest.

comment:12 Changed 17 years ago by SF/e8cal1

CVS 020505 (monkey2)
compiled with cxx says:
DEBUG: 4d414e52 524e414d
Error(0:0:0x0): Bad ID RNAM found in directory!!

compiled with g++ says:
DEBUG: 4d414e52 4d414e52
DEBUG: 5358414d 4d414e52
DEBUG: 4f4f5244 4d414e52
DEBUG: 00c65e00 4d414e52
Error(0:0:0x0): Bad ID !

cxx (but not g++) also warns alot about "conversion from
pointer to smaller integer".

The long => int thing doesn't make any noticable difference.

comment:13 Changed 17 years ago by SF/bbrox

Well, it seems that CXX does not like our 'MKID' macro (as
the result for MKID('RNAM') should be in hexadecimal
0x4D414E52 and not 0x524E414D). Seems like CXX is using the
Big Endian version of MKID...

Otherwise, for the G++ problem, I will look at it this
evening. We will need to add more debug informations :-)

comment:14 Changed 17 years ago by SF/ender

Any progress on this? I want to be able to start closing
some bugs to get the bug list down :)

comment:15 Changed 17 years ago by fingolfin

Just FYI, when Exult was ported to Alpha, it turned out
that gcc on Alpha produced buggy code (i.e. the code
generator is bugged!). In the end, Christoph (who did
the port) just gave up on G++/Alpha altogether for this
reason, and only used CXX.

comment:16 Changed 17 years ago by SF/ender

I'm moving this bug to Pending for the moment, as there have
been no updates. If anyone comes up with more information,
reopen this bug :)

comment:17 Changed 17 years ago by SF/ender

Status: newclosed

comment:18 Changed 7 months ago by digitall

Component: --Unset--Ports
Note: See TracTickets for help on using tickets.