[Bug report] Problem with new version of SheepShaver

Zincarlo · Post by **Zincarlo** » Tue Jun 15, 2004 1:05 pm

I tryed all available versions of new SheepShaver snapshot, but none works.

Here is the details:
1) First version from winter'03 compiled and runs fine
2) All new snapshots of 2.2 version compiled fine (i tryed all avaible sources, from cvs, from tar.gz at official site), but after "Reading ROM.." it just exits to console without any error. I even tryed precompiled binary from official site (i586.rpm) - the same problem, just exits after "Reading ROM". Nothing unusual with $strace SheepShaver
3) But old version from winter 2003 - works!

Only one idea, my linux box does not have floppy drive, but i think SheepShaver 2.2 somehow tryes to access /dev/fd0, and when not find it - exits.. [But old version from winter'03 works OK]

I tryed to remove /dev/fd0 from sources, but after compiling it exits with error.

gb · Post by gb » Tue Jun 22, 2004 4:45 pm

Could you try to run it as follows: "./SheepShaver; echo $?" (without double quotes) so that we can have a chance to get the exit code.

Besides, in ~/.sheepshaver_prefs, please set "ignoresegv" to "false" so that you don't end up into unexpected locations on real SIGSEGV.

Note: if your CPU doesn't support the CMOV instruction, it's very likely SheepShaver will crash with JIT enabled (causing a SIGILL). What happens with you set "jit" to "false"?

ShadowFox · Post by **ShadowFox** » Tue Jun 22, 2004 10:17 pm

I guess the other question is what type of ROM is it. Is it the MOL one from the OS 8.6 cd?

Zincarlo · Post by **Zincarlo** » Fri Jun 25, 2004 4:30 pm

Thanks for answering!

Here is the results (compiled cvs checkout from 2004-06-21, gcc-3.3.2):

=========
[zincarlo@hotha]$ ./SheepShaver; echo $?
SheepShaver V2.2 by Christian Bauer and Mar"c" Hellwig
Reading ROM file...
255
[zincarlo@hotha]$
=========

The same result with "ignoresegv" set to "false"
And the same result with JIT Compiler and built-in 68K DR Emulator turned on and off...

Here is the strace info:
=========
[zincarlo@hotha]$strace ./SheepShaver

[[[[skipped all lines before pressing "Start" button]]]]

wait4(4149, Reading ROM file...
[WIFSIGNALED(s) && WTERMSIG(s) == SIGABRT], 0, NULL) = 4149
--- SIGCHLD (Child exited) ---
_exit(-1) = ?
[zincarlo@hotha]$
=========

CPU is Celeron Tualatin 1000A, as of /proc/cpuinfo, there is CMOV in flags

But old winter '03 versions still run fine...

((((

gb · Post by gb » Fri Jun 25, 2004 4:49 pm

You can turn on DEBUG in main_unix.cpp, video_x.cpp so that you can have some debug info emitted. Besides, can you try with "nogui" set to "true" so that the gtk gui is not used?

exit(-1) is not something I use. What about gdb ./SheepShaver (on the unstripped binary), then "run" and "bt" commands. In case there is something useful from the backtrace.

Zincarlo · Post by **Zincarlo** » Fri Jun 25, 2004 4:59 pm

Thanks for helping!

Ok, here is gdb:
===========
[zincarlo@hotha]$ gdb ./SheepShaver

[[[[[skipped gdb "welcome" lines]]]]

This GDB was configured as "i386-redhat-linux"...
(gdb) run
Starting program: /tmp/3/SheepShaver
[New Thread 1024 (LWP 4595)]
SheepShaver V2.2 by Christian Bauer and Mar"c" Hellwig

Program exited with code 0377.
(gdb) bt
No stack.
(gdb)
============

Ok, now i'll try to recompile without gui and with DEBUG, and post results.

Zincarlo · Post by **Zincarlo** » Fri Jun 25, 2004 5:15 pm

Ok, here is the results:

1) set "nogui" to true

=========
[zincarlo@hotha]$ ./SheepShaver; echo $?
SheepShaver V2.2 by Christian Bauer and Mar"c" Hellwig
Reading ROM file...
255
[zincarlo@hotha]$
=========

2) compiled new binary (same cvs checkout source tree) with #define DEBUG 1
=========
[zincarlo@hotha]$ ./SheepShaverDebug; echo $?
SheepShaver V2.2 by Christian Bauer and Mar"c" Hellwig
PVR: 000c0000 (assumed)
Kernel Data at 0x68ffe000, Emulator Data at 0x68fff000
DR Cache at 0x69000000
ROM area at 40800000
RAM area at 20000000
Reading ROM file...
Loading XPRAM default values
255
[zincarlo@hotha]$
==========

Zincarlo · Post by **Zincarlo** » Fri Jun 25, 2004 5:32 pm

Now, for experiment, i again compiled old version (i checked out this version at 07 december 2003).

=========
[zincarlo@hotha]$ strace ./SheepShaverOld

[[[[[skipped lines before pressing "Start button"]]]]]

wait4(11933, Reading ROM file...

[[[[[here is SheepShaver Main Emulation window appeared]]]]]]

PowerPC CPU emulator by Gwenole Beauchesne

[[[[[emulation works fine]]]]]
==========

gb · Post by gb » Fri Jun 25, 2004 5:33 pm

OK, the emulation thread has not even started. Can you define DEBUG in rom_patches.cpp, video_x.cpp and add some printf("whatever you want\n"); in main_unix.cpp around *Init() functions?

Zincarlo · Post by **Zincarlo** » Fri Jun 25, 2004 6:02 pm

Ok, i defined DEBUG 1 in main_unix.cpp, rom_patches.cpp, video_x.cpp.

And also added printf (started from ZinCarlo>>>

) near *Init() functions in main_unix.cpp

Here is results:

=========
[zincarlo@hotha]$ ./SheepShaverDebug2
SheepShaver V2.2 by Christian Bauer and Mar"c" Hellwig
ZinCarlo>>>Read preferences
PVR: 000c0000 (assumed)
ZinCarlo>>>Init system routines
Kernel Data at 0x68ffe000, Emulator Data at 0x68fff000
DR Cache at 0x69000000
ZinCarlo>>>Trying to create area for SheepShaver data...
ZinCarlo>>>Trying to Create area for Mac ROM...
ROM area at 40800000
RAM area at 20000000
Reading ROM file...
Offset of compressed data: 00010db0
Size of compressed data: 001ca2e2
ZinCarlo>>>Load NVRAM
Loading XPRAM default values
ZinCarlo>>>Trying to init thunks....
[zincarlo@hotha]$
==========

Zincarlo · Post by **Zincarlo** » Fri Jun 25, 2004 6:43 pm

Additional info. Right now, i checked out cvs. And compiled it with --enable-sdl-video

here is test run:
==========
[zincarlo@hotha]$ ./SheepShaverSDL; echo $?
SheepShaver V2.2 by Christian Bauer and Mar"c" Hellwig
Reading ROM file...
Aborted
134
[zincarlo@hotha]$
==========

here is strace test run:
==========
write(1, "Reading ROM file...\n", 20Reading ROM file...
) = 20
lseek(12, 0, SEEK_END) = 1945746
lseek(12, 0, SEEK_SET) = 0
mmap2(NULL, 4198400, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40d00000
read(12, "<CHRP-BOOT>\r<COMPATIBLE>\riMac,1 "..., 4194304) = 1945746
close(12) = 0
munmap(0x40d00000, 4198400) = 0
open("/home/zincarlo/.sheepshaver_nvram", O_RDONLY) = -1 ENOENT (No such file or directory)
access("/dev/.devfsd", F_OK) = -1 ENOENT (No such file or directory)
access("/dev/fd0u1440", W_OK) = 0
open("/proc/mounts", O_RDONLY) = 12
fstat64(12, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40498000
read(12, "rootfs / rootfs rw 0 0\n/dev/root"..., 1024) = 175
read(12, "", 1024) = 0
close(12) = 0
munmap(0x40498000, 4096) = 0
open("/dev/fd0u1440", O_RDWR) = -1 EROFS (Read-only file system)
open("/dev/fd0u1440", O_RDONLY) = 12
fstat64(12, {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 28), ...}) = 0
ioctl(12, FDGETDRVSTAT, 0xbffff790) = 0
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
kill(18944, SIGABRT) = 0
--- SIGABRT (Aborted) ---
+++ killed by SIGABRT +++
[zincarlo@hotha]$

Zincarlo · Post by **Zincarlo** » Fri Jun 25, 2004 7:11 pm

When i recompiled it without SDL (i mean current cvs) - it crashes similiar to previous snapshot, mentioned in beggining of thread (i.e.:
===========
wait4(23744, Reading ROM file...
[WIFSIGNALED(s) && WTERMSIG(s) == SIGABRT], 0, NULL) = 23744
--- SIGCHLD (Child exited) ---
_exit(-1)
===========
and with echo $?:
===========
SheepShaver V2.2 by Christian Bauer and Mar"c" Hellwig
Reading ROM file...
255
===========

gb · Post by gb » Sat Jun 26, 2004 4:38 am

First, don't use SDL on Linux. That version will never be as featured nor as fast as the raw X11 version.

Second, please continue to printf() until you succeed in finding out exactly where SheepShaver is exitting (it's not a crash). This strace doesn't help at all. If you really want a trace, use gdb as mentioned earlier. (gdb ./SheepShaver, then type "run" and "bt").

It's indeed calling abort(). So, if you prefer going the printf() route, you can add some printf() before the abort(); in video_blit.cpp, video_x.cpp, thunks.cpp, etc.

Zincarlo · Post by **Zincarlo** » Sat Jun 26, 2004 8:38 am

Hello!

After adding more printf's - I found something!!

1) The first crash was here:
sony.cpp and cdrom.cpp, at the lines:

sony.cpp:
====
void *fh = Sys_open(str, read_only);
if (fh){
>> HERE>> drives.push_back(sony_drive_info(fh, SysIsReadOnly(fh)))
}
====

cdrom.cpp:
====
while ((str = PrefsFindString("cdrom", index++)) != NULL) {
void *fh = Sys_open(str, true);
if (fh)
>>HERE>> drives.push_back(cdrom_drive_info(fh));
}
}
====

After i commented "drives.push_back" in both cdrom and sony, the next exit was in extfs.cpp:

In void ExtFSInit(void) at the line:
FSItem *p = new FSItem;

I.e. i put printf before this line, and after this line, but only first printf works, and there emu exits (i.e. it can't do this thing "FSItem *p = new FSItem;")

Zincarlo · Post by **Zincarlo** » Sat Jun 26, 2004 8:52 am

After i commented ExtFSInit(), ADBInit(), SerialInit(), the emulation window appeared, but suddenly quits.

gb · Post by gb » Sat Jun 26, 2004 10:16 am

For some reason, you seem to run out of memory and the C++ runtime is likely throwing std::bad_alloc. And since any uncaught exception makes the program abort(), that seems to be normal behaviour in this condition.

However, I don't how you could run out of memory. To validate this hypothesis, could add something like the following into main_unix.cpp:

try {

ADBInit();
AudioInit();
// ... anthing else you want up to emul_thread = pthread_self();

}
catch (std::bad_alloc const & e) {
perror("std::bad_alloc thrown");
exit(1);
}

Note: make sure to #include <errno.h> and <new> in the includes section.

The only extra memory region mapped from previous release is the DRCache and DREmulator areas. You can try disabling that initialization with some #if 0 ... #endif surrounding the lines for "Create are for DR Cache". Of course, don't enable "jit68k" afterwards.

Zincarlo · Post by **Zincarlo** » Sat Jun 26, 2004 12:05 pm

Ok.

After i placed "try {" right before ADBInit(), it exits without any info.

But then i placed "try {" before SonyInit(), then i got it:
=====
SheepShaver V2.2 by Christian Bauer and Mar"c" Hellwig
Reading ROM file...
std::bad_alloc thrown: Read-only file system
=====

But when i placed "try start point" right after SonyInit(), then it again exits w/o any info.

Moreover, i commented SonyInit() and placed try { before CDROMInit(), and got this:
=====
Reading ROM file...
std::bad_alloc thrown: Success
=====

More, i commented CDROMInit(), place try { before ExtFSInit(), and got the same:
=====
Reading ROM file...
std::bad_alloc thrown: Success
=====

ok, then the same was with ADBInit and SerialInit, when i comment them, i got emulation window started and closed w/o any error.

I tryed to disable creating area for DR caching, but it still exited

gb · Post by gb » Sun Jun 27, 2004 8:29 pm

So you are running out of memory. A possible reason may be malloc() is now failing through sbrk(). This could happen if the executable is remapped near 0x20000000, then sbrk() reachiing allocated Mac RAM, sees that already allocated and can no longer allocate memory.

What sort of system do you have? Is that that sort of system capable to remap at arbitrary addresses the executable? e.g. Fedora Core something. One way to check that is through readelf -l SheepShaver and check VirtAddr, or check through /proc/<pid>/maps if there is something really near the Mac RAM region at 0x20000000.

If this is the case, I could enhance SheepShaver on Linux to build with a dedicated GNU ld script so that executable sections are placed at fixed regions. But this is planned for later so that more than 512 MB could be allocated to SheepShaver.

Zincarlo · Post by **Zincarlo** » Mon Jun 28, 2004 4:08 pm

Hello!

Thanks for helping and for great emu!

Here is some info about my system:
RedHat 7.3, glibc 2.2.5-34, kernel 2.4.18-3
two gcc (and corresponding libstdc++): 2.96 and 3.3.2

(With 2.96 SheepShaver can't compile, so i use 3.3.2)

Is it possible to fix memory allocation problem via upgrade of glibc?

btw, here is readelf info:
===
readelf -l SheepShaver
Elf file type is EXEC (Executable file)
Entry point 0x80760d0
There are 7 program headers, starting at offset 52

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x000e0 0x000e0 R E 0x4
INTERP 0x000114 0x08048114 0x08048114 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
LOAD 0x000000 0x08048000 0x08048000 0xa28f4 0xa28f4 R E 0x1000
LOAD 0x0a3000 0x080eb000 0x080eb000 0x04b24 0x10f38 RW 0x1000
DYNAMIC 0x0a7488 0x080ef488 0x080ef488 0x00150 0x00150 RW 0x4
NOTE 0x000128 0x08048128 0x08048128 0x00020 0x00020 R 0x4
GNU_EH_FRAME 0x0a1c00 0x080e9c00 0x080e9c00 0x00cf4 0x00cf4 R 0x4
===

About virtualmem maps, im not any really good in this =) but if i understand it right, seems that here is no one process uses 0x20000000 (and any near adr) on my system (i look through all /proc/<*pids*>/maps) - seems that all processess use only 0x08nnnnnn, 0x4nnnnnnn and 0xbfffnnnn...

Zincarlo · Post by **Zincarlo** » Mon Jun 28, 2004 4:35 pm

...continue

Im not sure what i do =) but i tryed this:
when in one console i runned SheepShaver, in other console i do this:

$cat /proc/*/maps | grep 0-2

and got this:
20000000-21000000 rw-p 00000000 00:00 0

But if there is no running SheepShaver, i got nothing on this search (grep "0-2" in /proc/*/maps), so seems that is nothing use nnnnnnnn-2nnnnnnn space...

To be sure i did this, after running SheepShaver:
$ cat /proc/`pidof -s SheepShaver`/maps | grep 0-2
20000000-21000000 rw-p 00000000 00:00 0

So seem that only SheepShaver uses 0x20000000