#206 closed defect
Tru64 runtime error
| Reported by: | SF/e8cal1 | Owned by: | SF/bbrox |
|---|---|---|---|
| Priority: | normal | Component: | Ports |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
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: /users/etek/e98/e8cal1/.scummvmrc.
ScummVM - Scumm Interpreter Syntax: scummvm [-v] [-d[<num>]] [-n] [-b<num>] [-t<num>] [-s<num>] [-p<path>] [-m<num>] [-f] game Flags: -v - show version info and exit -c<num> - use cdrom <num> for cd audio -d[<num>] - enable debug output (debug level [1]) -n - no subtitles for speech -b<num> - start in room <num> -t<num> - set music tempo (suggested: 1F0000) -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 (normal,2x,3x,2xsai,super2xsai,supereagle,advmame2x) -a - specify game is amiga version -w[<file>] - write to config file [~/.scummvmrc] -l<file> - load config file instead of default Error: Freeing invalid block.!
> ./scummvm -v Unable to open configuration file: /users/etek/e98/e8cal1/.scummvmrc.
Error: Freeing invalid block.!
/Anders Lindström
Ticket imported from: #550946. Ticket imported from: bugs/206.
Change History (18)
comment:1 by , 22 years ago
comment:3 by , 22 years ago
With CVS from 20020502 the "Freeing invalid block" error is gone. But scummvm now crashes when loading an game:
./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 by , 22 years ago
Did you try enabling in scummsys.h the following line :
#define SCUMM_NEED_ALIGNMENT
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 by , 22 years ago
| Owner: | set to |
|---|
comment:6 by , 22 years ago
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 by , 22 years ago
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 by , 22 years ago
sizeof() 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); #undef COMPILE_TIME_ASSERT
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, 0x12002bfc0] 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 by , 22 years ago
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 by , 22 years ago
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 by , 22 years ago
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 by , 22 years ago
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 by , 22 years ago
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 by , 22 years ago
Any progress on this? I want to be able to start closing some bugs to get the bug list down :)
comment:15 by , 22 years ago
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 by , 22 years ago
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 by , 22 years ago
| Status: | new → closed |
|---|
comment:18 by , 5 years ago
| Component: | --Unset-- → Ports |
|---|
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.