#4363 closed defect (fixed)
WOODRUFF: Yellow screen after using tobozon and then crash
| Reported by: | SF/plkolek | Owned by: | DrMcCoy |
|---|---|---|---|
| Priority: | high | Component: | Engine: Gob |
| Version: | Keywords: | ||
| Cc: | Game: | Woodruff |
Description
ScummVM version - 14.0 SVN last update: June 11, 2009, 1:42 am and 13.1 Language of game - polish Version of game - CD from a magazine, firstly installed using wine, then copied to the directory i wanted Platform and Compiler - Ubuntu 9.04 x86_64 and Windows XP
Bug details: I play the polish version of Woodruff, so it will be hard for me to translate some names. After using tobozon (that ehm phone?) I place my mouse on the slot in tobozon. The part of the screen becomes yellow, on the bottom of the screen are many letters - too many, overriding each other. If I am quick enough, i can click somewhere, so the tobozon (the part where it was isn't yellow) disappears and i can exit the game. Otherwise, it hangs my xorg (i think so, using console, i can kill xorg and then start it again. Killing scummvm doesn't work). The symptoms on Windows are different - the screen is not yellow, but there is a thin, strange diagonal line one the left. Letters on the bottom are messed too. Fortunately on Windows I am able to continue the game.
I tried both stable and newest version - no difference. One time, on the newest version the bug didn't occur, and i could read a "hidden" (?) message on the bottom - no messed letters.
If I can give you more information plesa ask, maybe i forgot about something ;)
Ticket imported from: #2804962. Ticket imported from: bugs/4363.
Attachments (4)
Change History (24)
by , 15 years ago
| Attachment: | woodruff.s00 added |
|---|
comment:1 by , 15 years ago
Hmm, can't reproduce it here. Must be something specific to the Polish version then, like with the Italian version.
This smells like a memory corruption. Since you're on Linux, could you try running it in valgrind and attach the output here?
(If you don't know how to use valgrind, here's the gist: run "valgrind --log-file=WoodruffCrash scummvm", and provoke the crash)
comment:2 by , 15 years ago
| Owner: | set to |
|---|
comment:3 by , 15 years ago
| Summary: | Yellow screen after using tobozon and then crash → WOODRUFF: Yellow screen after using tobozon and then crash |
|---|
comment:4 by , 15 years ago
| Priority: | normal → high |
|---|
comment:5 by , 15 years ago
I ran Woodruff in valgrind. Most important notice - it caused unpredictable behaviour of the game, but in another way. Now several 1 pixel black lines appeared in erm... let's say action part of the screen (Woodruff and world are there). The black, bottom part with the names of the objects became white for a moment. It didn't cause the game to hang or crash, I could reproduce it many times.
Not related to the bug and topic. You guessed correctly, it was my first run of valgrind, as it is my first bug submission. I was shocked, that program writing logs can slow down my game so much.
If it is specific to the Polish version, i suppose it will be hard or impossible for you to fix it?
comment:6 by , 15 years ago
"it caused unpredictable behaviour of the game"
Well, a memory corruption produces "Undefined Behaviour" which might do /anything/, including eating your grandmother ;).
"I was shocked, that program writing logs can slow down my game so much"
Well, valgrind is more than a simple program writing logs. It basically emulates a CPU and catches specific calls to memory related functions. This is pretty slow, since it translates every tiny CPU instruction into dozens of instructions.
"If it is specific to the Polish version, i suppose it will be hard or impossible for you to fix it?"
Depends. A good log can help. I'd start with running valgrind here too, since it's one of the few good ways of debugging memory related bugs.
Unfortunately, it seems your binary doesn't have debug symbols compiled in. I can see it does some funky stuff, but not where. Did you compile it yourself? If so, could you add "-ggdb" to one of the CXXFLAGS-lines in the Makefile, recompile and retest?
comment:7 by , 15 years ago
Ah, another thing, if you don't know that already: be sure to check that you actually use the correct binary. If you've got a self-compiled binary in the current directory, but an old one from your distribution still in /usr/bin/ or /usr/games/ or somesuch, simply typing "scummvm" will call the latter. You need to call "./scummvm" to execute the one in the current directory (and if you're running valgrind, it's then "valgrind --log-file=WoodruffCrash ./scummvm".
comment:8 by , 15 years ago
Again, I will start with things strictly connected to the bug. I am running ScummVM from the download site - it is Ubuntu .x66 .deb package. So I didn't compile anything, I don't have the problem with choosing the correct binary. But... if you use your time, skill and will to help, I have to help as much as I can. Tomorrow I will try compiling the program. There might be a problem - I have never succeeded compiling a program written not by me. I had problems every time I tried, but I hope this time there won't be any.
I am an amateur programmer, so I have never written a big application. Mostly my programs are short algorithms for contest, but I met the undefined behaviour of memory problems. Fortunately the code was too short to eat any member of my family.
Valgrind? Oh i forgot to add ";)" after the "log-writing" sentence. My bad. Of course I checked what you made me install, especially because it was about 50MB download. So I know in general what it does, but I don't have enough knowledge to know how it works. And it will take some years I think before I will have to use such a framework.
comment:9 by , 15 years ago
"I am running ScummVM from the download site - it is Ubuntu .x66 .deb package."
Hmm, apparently that's been stripped of debug information then. :/
"There might be a problem - I have never succeeded compiling a program written not by me"
ScummVM is one of the easy compiling packages out there. Should you have any problems though, just ask and I'll try to help.
"Fortunately the code was too short to eat any member of my family"
Maybe it ate and then impersonated them? ;)
"Valgrind? [...] So I know in general what it does"
:)
comment:10 by , 15 years ago
I am lucky! Eventually... It is the first time , when nothing could go wrong and nothing wnet wrong. Usually "make" wasn't so good for me ;). Compiled with -ggdb flag (I din't know where exactly to put it, but then I realized that it doesn't matter) and I think it works. Again, the undefined behaviour is really undefined. No visual effects, but a major 2-3 seconds stop in the game. And then working again. Because of that I tried more times than usual to reproduce the bug, and the log is longer. "ERROR SUMMARY: 112900 errors from 20 contexts" - I hope I will see my mum again!
Hmmm... Why the debug information are not provided in the testing packages? They are unstable (mine works without any problems for now, but it doesn't matter), for people who know what to do, then there must be some negatives of including that option. I'm sure you will reply, at least with a link ;)
comment:11 by , 15 years ago
Thanks! I'll look into that. :)
"Why the debug information are not provided in the testing packages"
No idea. Hopefully that situation will resolve itself once we offer binaries from our buildbot that's currently in the testing stage.
comment:12 by , 15 years ago
Could you retry with a recend SVN checkout (r41497)? I've just commited something that might fix it.
comment:13 by , 15 years ago
Is there any way to download that specific version of ScummVM(r41497)? I went tohttp://helllabs.org/scummvm/ and downloaded the 20090613 source. Is that OK?
comment:14 by , 15 years ago
Nope, that one hasn't got the needed changes yet.
You can either wait, or pull the sources directly from SVN, by installing subversion and executing svn co https://scummvm.svn.sourceforge.net/svnroot/scummvm/scummvm/trunk scummvm
comment:15 by , 15 years ago
I did what you wanted me to do - downloaded from SVN and compiled it. That works! Thank you very much, I don't have to worry about the crash while using tobozon. Is the problem definitely fixed now, or should I post some logs with effects of that fix?
BTW I am really amazed with what you did. Only three days after submitting a bug it is solved, even though you didn't have polish version of the game. I like this so much, that expect me to look for bugs everywhere now :D
comment:16 by , 15 years ago
"Is the problem definitely fixed now, or should I post some logs with effects of that fix"
Yes, please. To be sure it's not just a coincidence.
"Only three days after submitting a bug it is solved, even though you didn't have polish version of the game"
Well, your logs brought me upon the function that crashed and then I looked into the disasm of that function and saw that the offset within the text table is copied with movzx, i.e. it should be unsigned, not signed. Which would explain the crash, when in your version the offset exceed 3767.
Let's hope it actually is the correct fix. When the log comes out empty of warnings/errors now, then we can be sure. :)
by , 15 years ago
| Attachment: | WoodruffNoCrash added |
|---|
Valgrind output with debug information - no errors
comment:18 by , 15 years ago
Valgrind doesn't show any errors, then the bug is fixed. I won't ask any more questions, not to make off-topic and take your time, so again thank you!
comment:20 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Savegame - use tobozon to crash