Bug#443822: I've found a fix (for: hex-a-hop: Got bt from a segfault :D)

[Bas Wijnen]

On Sat, Nov 22, 2008 at 06:23:12PM +0100, Gerfried Fuchs wrote:
> > Maybe a memory checker such as efence would help as well, not sure.
> 
>  How would I incorporate it?

The easiest is (when it's installed; it's called electric-fence) to give
the command "efence" in gdb, and then run it.  The result should be that
it fails early instead of late when messing with the heap.

But given your following mails, I don't think you still need it.

On Sat, Nov 22, 2008 at 06:33:00PM +0100, Gerfried Fuchs wrote:
>  Hmm, there is one message it spits out over and over again though:
> 
> ==10317== Source and destination overlap in memcpy(0x48AE628, 0x48AE62C, 2556)
> ==10317==    at 0xFFBCF94: memcpy (mc_replace_strmem.c:402)
> ==10317==    by 0x872B024E: ???
> ==10317==    by 0xFF11D10: (within /usr/lib/libSDL-1.2.so.0.11.1)
> ==10317==    by 0xFF29468: SDL_LowerBlit (in /usr/lib/libSDL-1.2.so.0.11.1)
> ==10317==    by 0xFF29680: SDL_UpperBlit (in /usr/lib/libSDL-1.2.so.0.11.1)
> ==10317==    by 0x1002148C: HexPuzzle::Render() (hex_puzzzle.cpp:2629)
> ==10317==    by 0x10004260: main (gfx.cpp:402)
> 
>  That line in hex_puzzzle.cpp says:
>     SDL_BlitSurface(screen, &src, screen, &dst);
> 
>  It's the only call to that function with twice the same argument
> (screen) in the whole source - might that be anything important?

Certainly.  This call with this error means that a part of the screen is
moved to itself.  It's quite unusual to copy things from screen to
screen anyway; usually it's from offscreen pixmap to screen.  So it's a
good idea to check what is supposed to be copied here.

So I did that.  The if on line 2608 is around the code for making the
waves in the water.  It would all work fine, if it wouldn't be copying
from screen to screen (I think).

However, now that it does that, memcpy isn't too happy.  This should be
solved by drawing things to a temporary surface first and blitting that
(with offsets) to screen.  Care should be taken to avoid ugly edge
effects.  In particular, the SDL documentation doesn't say that negative
source coordinates are handled well.  And they can happen.  This should
probably be rethought.

For now, a solution can be to turn if (1) into if (0).  That removes the
waves from the water, and avoids the whole problem.

It would be interesting to know if that also solves the crashes, though.
I'm inclined to think that it shouldn't.  The result of this code seems
to be a messed up screen, but not a messed up memory.  So please test
it. :-)

On Sat, Nov 22, 2008 at 06:45:52PM +0100, Gerfried Fuchs wrote:
>  Got a crash now:

That could be very useful, I think.  So far, I didn't take the time to
look at this.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20081123/d9a3afb3/attachment.pgp