Opened 13 years ago

Closed 12 years ago

Last modified 13 months ago

#3125 closed defect (fixed)

MACOSX: Crash with zlib

Reported by: SF/mthreepwood Owned by: vinterstum
Priority: normal Component: Port: Mac OS X
Keywords: Cc:
Game:

Description

When I tried to play Backyard Baseball with the universal svn build, it crashes with this error:

backends/saves/compressed/compressed-saves.cpp:214: failed assertion `_zlibErr == Z_OK'

Mac OS X 10.2.8

Ticket imported from: #1681755. Ticket imported from: bugs/3125.

Change History (29)

comment:1 by SF/mthreepwood, 13 years ago

Oops... forgot to say the March 15 build

comment:2 by fingolfin, 13 years ago

Hm, but earlier you said you couldn't even launch it. What now? I am confused

comment:3 by SF/mthreepwood, 13 years ago

This time I used the universal build. Before I couldn't launch with the PPC build.

comment:4 by vinterstum, 13 years ago

Yeah looks like the PPC build got corrupted somehow, I'm looking into it now.

comment:5 by vinterstum, 13 years ago

Owner: set to vinterstum

comment:6 by vinterstum, 13 years ago

I suspect both of these bugs were due to the corrupted archives; please give the newly uploaded ones a spin and see if it still happens.

comment:7 by SF/mthreepwood, 13 years ago

Although I don't have Backyard Baseball with me now, I know this isn't from this build only. I went back to my build from the 27th and the bug was still there.

comment:8 by fingolfin, 13 years ago

I am playing the "Backyard Baseball 2001" over here. No crash. Please tell us precisely:

* Are you refering to specifically "Backyard Baseball 2001" ?
* What are the precise steps needed to reproduce the issue?
* Can you reproduce the issue with the demo, too?

comment:9 by fingolfin, 13 years ago

This tracker item is pending response by the submitter; we
cannot continue processing it before that happens. As a
consequence, its status has been set to "Pending". It will
automatically revert to "Open" once a new comment is made to
this item. If no response is made within 14 days, it will
automatically be closed.

Thank you.

comment:10 by fingolfin, 13 years ago

Status: newpending

comment:11 by SF/mthreepwood, 13 years ago

I am still able to reproduce. (With PPC build from 3/16)

I also tried saving with Indy3 DOS VGA and I get the same error. It always loads a certain file (managers?) from Backyard Baseball and therefore always crashes.

Heh. Forgot about this report... :P

comment:12 by SF/mthreepwood, 13 years ago

Status: pendingnew

comment:13 by vinterstum, 13 years ago

Hmm I'm completely unable to reproduce this one.

Any chance you have a comflicting version of zlib installed? (Via Darwinports or Fink?)

comment:14 by fingolfin, 13 years ago

Sounds unlikely. Fink doesn't ship a zlib for a long time now, but even if it (or MacPorts, as DarwinPorts is called now) did, then how would that cause the errors?

Besides, the binary was linked on your machine, right? Then it would only depend on which zlib version is installed on *your* system, vinterstum. You can find out by running "otool -L" on you scummvm binary. The full path to libz is encoded there.

comment:15 by vinterstum, 13 years ago

DarwinPorts definately comes with its own version of zlib, I have to specifically deactivate it every time I build scummvm (the command for it is even included in my build scripts).

And zlib doesn't get statically linked in either, so if the darwinports version is first in the library path...

To mthreepwood/clone: Could you try to do a "sudo port deactivate zlib" and then rerun ScummVM?

It is, of course, possible that something has gotten messed up on my PPC build machine. The timing is just odd, since I haven't made any changes to the build setup there for a long time.

comment:16 by fingolfin, 13 years ago

"And zlib doesn't get statically linked in either, so if the darwinports version is first in the library path..."

Well, if you dynamic link against /usr/lib/libz.dylib, then this gets encoded into the binary. It will *not* use /some/other/path/libz.dylib -- so if you built the binary correctly, it should work fine even for people who have fifty alternate versions of zlib installed all over the place.

Hence my question whether you checked the binary you uploaded with "otool -L" -- this way you can easily see if the correct library path got linked in.

comment:17 by vinterstum, 13 years ago

Ahh, interesting. Guess I'm still too used to Linux, had assumed the behaviour was the same.

Anyway, otool dumps out:

/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)

...which sounds correct.

comment:18 by fingolfin, 13 years ago

Hrm, we are not getting further with this, are we?

Yet another idea: Maybe there is a header mismatch. I.e. you are linking to the right version of zlib, but maybe during compilation the header file of a different version is used.
Although at least in theory, this should *not* cause problems as we are seeing... Hrm.

Maybe I should make a PowerPC build available, too, as PPC is my main development platform and it works fine for me here?

comment:19 by fingolfin, 13 years ago

I just tried the March 16 PowerPC build from http://worldsmainorganization.org/scummvm/

So, I tried to save and load games in Indy 3 EGA. Worked fine. Same for "Backyard Baseball 2001"

All on Mac OS X 10.4.9, though. Maybe it boils down to an incompatibility with OS X 10.2.8 ?

comment:20 by vinterstum, 13 years ago

That's certainly possible. It would be nice to narrow down whether it's a problem on my end or on his end though, a build by you would help that (Though building all the deps against the 10.2.8 SDK takes some time).

Clone/mthreepwood: I just uploaded a build that has zlib statically linked into it, please give it a try :)
http://worldsmainorganization.org/scummvm/?dir=&download=scummvm-snapshot-ppc-zlibstatic.dmg

comment:21 by SF/mthreepwood, 13 years ago

It appears to work. I was able to save/load in Indy 3 VGA. Unfortunately, I cannot test Backyard Baseball now.

comment:22 by fingolfin, 13 years ago

So, it seems we may have to static link zlib from now on if we want to keep 10.2.x compatibility?

comment:23 by sev-, 12 years ago

What is the status of this item?

comment:24 by vinterstum, 12 years ago

Fixed, I guess. Why we have to statically link in zlib to work on 10.2.8 now, I have no idea, but it seems to solve the problem.

comment:25 by vinterstum, 12 years ago

Resolution: fixed
Status: newclosed

comment:26 by fingolfin, 12 years ago

Hm, so you manually static link zlib on 10.2.8 ? That's not good, it means that other people won't be able to reproduce your builds...

It would be nice to either have the full build you are doing documented somewhere (including special tricks to hard link zlib, cross compiling hints, etc.). Even better would be if it could be done out of the box with a fresh checkout.

comment:27 by vinterstum, 12 years ago

Not statically link on 10.2.8 (I don't have any 10.2 boxes), just against a version of zlib I crosscompiled for 10.2.8. It's not really something I can change the makefiles for people to do out of the box, but I guess I can make a wiki page with the full process.

comment:28 by vinterstum, 12 years ago

http://wiki.scummvm.org/index.php/MacOS_X_Crosscompiling

comment:29 by digitall, 13 months ago

Component: Port: Mac OS X
Note: See TracTickets for help on using tickets.