memset crash (or something completely different)

Raziel · Post by **Raziel** » Fri Feb 22, 2013 5:00 pm

I am doing the port of residualvm to AmigaOS4 which is based on ScummVM and as such relies heavily on SDL.
You can find the latest version on the Depot
The source code is here: http://github.com/residualvm/residualvm

The problem i have is that it will always crash when i switch to fullscreen (ALT+ENTER), no mattre if Software or Hardware Renderer is used.

It works on ALL other platforms (even BE) and given that the code is pretty much based on ScummVM (where the fullscreen switch is working) i am about to blame some other function which is coughing up, but i'm no coder so i can't really tell

(I do know that residualvm is using some alternations though)

The real problem is that i can pinpoint the function crashing with a debug build and addr2line(*), but, unfortunately, can't get gdb to output a useable and readable backtrace. Only with a backtrace the original devs can work with the bug report (due to not being able to debug on a machine they don't have) and eventually fix the crash.

(*) The line i used is: addr2line --section=.text -C -fe residualvm 0x0x26154c

I have hidden a crashlog which is reproduceable everytime but of course this is the case where it especially crashes in the source of residualvm. It's crashing always in the same function in residualvm's code...

graphics/pixelbuffer.cpp, line 88 (which is the closing quote of this function:

Code: Select all

void PixelBuffer::clear(int length) {
    memset(_buffer, 0, length);
}

Now, because of this memset part i am about to blame SDL again, because the
changelog (http://www.libsdl.org/release/changes-1.2.html) states for version
1.2.14:

Fixed freeze in SDL_memset() with 0 length when assembly code is disabled.

Again i'm no programmer, so it may be something completely different going on here, but it fits so well and i'm always looking for similarities

(And of course i already realized that SDL_memset and memset are NOT the same)

After a short eMail discussion with Andrea Palmatè he suggested to post it on the forums because he believes it might be a problem in AmigaOS4...

from Andrea Palmatè:

I've seen the changes from our version and the (SDL) .15 and there is nothing related the fullscreen. If there is a problem is for sure in our version.

OK, so i may be completely wrong about this, again, sorry for any false accusations, i'm just no coder :-/
(I do have read in forums that some devs have switched to 1.2.15 because there was a nasty fullscreen bug which only affected BE machines and it went away once 1.2.15 were installed, but it seems that this is not the same case)

from a followup mail with Andrea

I'm a betatester but i prefer that someone with an X1000 will file the bugzilla entry since he can test it with his hands

Which i am doing now in the hope that the AmigaOS4 devs can probably point me in the right direction
I hope it's ok to put this in general as i do get the very same crash on an XE

Thanks a lot

Hidden Text - Click to Show :

Post by **tonyw** » Fri Feb 22, 2013 11:22 pm

The fact that it says 0xDEADBEEF should tell you immediately that you are trying to write to memory that has been freed already. It hasn't been cleaned and returned to the heap yet.

So look for a mechanism that would allow that to happen. Has the memory been freed a few lines back, then, before exiting the function, the programmer said "Oops! I'd better do this or that before the memory goes away!" ?

The usual way it happens is:

1. Program allocates memory.
2. Program uses memory.
3. Program releases memory.
4. Program does something else to the released memory. Now sometimes it will work if the memory handler has not yet got around to it, but other times it will crash because the freed memory has been filled with 0xDEADBEEF by the debug kernel. Of course, if you were using the "normal" kernel, it would probably crash much later, long after the evidence has been destroyed.

Unfortunately, if the memory has been allocated by one function (or Task) and released by another, a third function or Task can't tell from the memory pointer if it still exists or not. The function/task that allocated the memory (and presumably wrote down its pointer) must clear that pointer to NULL when the memory is released, so that others can see it does not exist any more.

Hyperion Entertainment Message Boards

memset crash (or something completely different)

memset crash (or something completely different)

Re: memset crash (or something completely different)