Opened 10 years ago
Closed 7 years ago
#6820 closed defect (fixed)
Crash to console collecting last stones under church
| Reported by: | SF/r-alf-the-alf | Owned by: | csnover |
|---|---|---|---|
| Priority: | blocker | Component: | Engine: Dreamweb |
| Version: | Keywords: | has-save-game has-pull-request | |
| Cc: | christoph@… | Game: | Dreamweb |
Description
I was told to post this as bugreport... ( http://forums.scummvm.org/viewtopic.php?p=81333#81333 )
I was playing the german version of dreamweb downloaded at scummvm.org, but also tried the uk disk and cd versions. Dreamweb crashed to console when i collected the second last (i think) stone under the church. As i started all over again, i could finish it perfectly, but collected far more less stuff than before.
ScummVM log:
[2015-02-20 14:28:40] WARNING: SDL mixer output buffer size: 2048 differs from desired: 4096! [2015-02-20 14:28:40] WARNING: You are missing a valid 'translations.dat' file. GUI translation will not be available! [2015-02-20 14:28:40] WARNING: Could not find theme 'scummmodern' falling back to builtin! [2015-02-20 14:29:15] Out of Ex object memory!
. To reproduce, just use the savegame and collect the 2 stones.
ScummVM Version: 1.7.0 OS: Linux Mint (Mate)
Ticket imported from: bugs/6820.
Attachments (1)
Change History (10)
by , 10 years ago
| Attachment: | DREAMWEB.D00 added |
|---|
comment:1 by , 10 years ago
comment:2 by , 7 years ago
| Cc: | added |
|---|
I've experienced the same bug, it also happened when piccking up the second last stone.
However, I experimented a bit; my findings so far:
1) The bug is not "tied" to this particular stone. Proof: I reloaded a file saved immediately before entering the church, touched no items this time except those necessary to proceed to the stones: I fetched the skeleton hand, took the items from the altar, dropped them immediately, then went down, picked only the 3 red and all grey stones while proceeding, ignoring the dagger. This time I could deposit all stones into the cart. However, the game crashed as soon as I went back to pick up the dagger from the grave.
2) It seems not purely accidentally that it occurred at the second last stone. It is extremely unlikely that the original reporter and I had accidentally picked up an identical number of things or something like that.
3) It is not directly related to the total number of things picked up. In my second attempt I took far less items than before, when I examined every bible and pillow, just to see if something was hidden beneath.
Additional thoughts:
This might be related to other glitches:
I thought that I might be able to write information to network cards, so I took with me all of them. Later in the game, the green one found in Louis' flat got its inventory graphics damaged. I dropped all empty cartridges in front of my network interface, but later found the green one in Louis' flat again, where it had initially been, the image was restored to normal. This also happened with other items: Eden's CDs and my cigarettes went back to the place where they were in the beginning. At first I thought that this might be intentional (Eden cleaning her flat), but why remained 2 cups and a knife on the floor, and why should she bring this network card back from MY flat to Louis, leaving everything else in a mess?
It seems that there is still something seriously messed up in the item handling code.
Version played: German 1.1 on ScummVM 1.9.0
comment:3 by , 7 years ago
| Priority: | normal → blocker |
|---|
Raising all identified crasher, hang, and memory violation bugs which I could not fully triage myself to blocker priority for the next release.
comment:4 by , 7 years ago
| Owner: | set to |
|---|
comment:5 by , 7 years ago
| Keywords: | has-save-game added |
|---|
comment:6 by , 7 years ago
I dropped all empty cartridges in front of my network interface, but later found the green one in Louis' flat again, where it had initially been, the image was restored to normal. This also happened with other items: Eden's CDs and my cigarettes went back to the place where they were in the beginning.
The game has a limit of remembering changes to 114 objects in the game world. If more than that are changed the engine starts starts purging them from the list so they will end up back where they started.
In this case the crash seems to be happening because the game cannot find an object to purge from this list, so there is no room to add the stone. I would guess there is some bug somewhere that is failing to set some flag indicating an object can be purged from the list, but I am still investigating. Worst-case, we have more memory so can probably just make this list dynamic, or at least increase its size so there can be more dynamic objects.
comment:7 by , 7 years ago
Later in the game, the green one found in Louis' flat got its inventory graphics damaged.
Hm, this sounds like #6196 again…
After a bit more investigating, there are actually many free slots for ex objects available, but not enough free memory left in the memory block used for frame data.
The code currently hard-codes the amount of needed extra memory in the frame data and text buffers when transferring an object to Ex memory, but this is way more memory than is actually needed here (it requires 4000 bytes free, but the new items only need a couple hundred bytes). So I have a patch to make this calculation accurate, which gets us past this particular OOM crash, though may not truly solve the overall problem of the game getting into a state where it cannot clear enough memory from the frame buffer to avoid running out and crashing.
A second issue is that I can’t account for all of the memory used in the frame buffer. When I calculate the expected size from the active Ex objects in the save game, I come up with 25937 bytes, but the free pointer is at 26342, so either I am misunderstanding something (very probable, I am not familiar with this engine) or 405 bytes have leaked out somewhere, which would be a problem if so since that’s 1.3% of the available memory for ex object frames! The only way I can see that this would happen would be if something is turning a kExObjectType DynObject into a different type of DynObject without going through deleteExObject to clear away the Ex frames data. I can also see that it is possible for DynObjects may get stuck and retain memory forever if they aren’t reset to values that allow purgeAnItem to purge them.
I guess the second issue doesn’t need to really be addressed right now, or maybe even ever since I don’t know that there is any technical reason that we really need to keep the entire game’s memory limited to 64k.
comment:8 by , 7 years ago
| Keywords: | has-pull-request added |
|---|---|
| Resolution: | → fixed |
| Status: | new → pending |
Let’s just go with the fix-up to free memory calculation for now since I have a bunch of other work to do. https://github.com/scummvm/scummvm/pull/1053
comment:9 by , 7 years ago
| Status: | pending → closed |
|---|
Thanks for your report! A patch for this issue has been added in commit a6659ba9d577998139cbb9a61532f823a24bc3b9 and will be available in daily builds 1.10.0git-5371 and later.
I just realized, that only the last line of the log actually represents the crash, the others come from starting scummvm.