#98 [lbreakouthd] Premature end (asserting "Congratulations")

[Oliver Kellogg]

On r567 of https://svn.code.sf.net/p/lgames/code/trunk/lbreakouthd built on current Tumbleweed x86_64, playing the custom level "Outbreak" spontaneously asserts end with "Congratulations, you have cleared all levels" early in the game.
Once, there was also an abort with
Floating point exception (core dumped)
but unfortunately, no corefile was written.

[Oliver Kellogg]

I ran lbreakouthd "Outbreak" in valgrind and short before the premature end, there were the following warnings:

Added player [...]
== Invalid read of size 4
==    at 0x41AF5C: ClientGame::isBrickAtPosition(int, int) (clientgame.h:170)
==    by 0x40C509: View::render() (view.cpp:589)
==    by 0x40B584: View::run() (view.cpp:442)
==    by 0x41537D: View::runMenu() (view.cpp:1447)
==    by 0x428E29: main (main.cpp:48)
==  Address 0xb730648 is 8 bytes after a block of size 96 free'd
==    at 0x484717B: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==    by 0x4AF2B62: ??? (in /usr/lib64/libSDL2-2.0.so.0.2600.2)
==    by 0x407AD4: Font::write(int, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int) (sdl.cpp:586)
==    by 0x43CD9C: SelectDialog::render() (selectdlg.cpp:210)
==    by 0x43D631: SelectDialog::run() (selectdlg.cpp:312)
==    by 0x4152A7: View::runMenu() (view.cpp:1440)
==    by 0x428E29: main (main.cpp:48)
==  Block was alloc'd at
==    at 0x48495EF: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==    by 0x4AF2C0B: ??? (in /usr/lib64/libSDL2-2.0.so.0.2600.2)
==    by 0x4AF3067: ??? (in /usr/lib64/libSDL2-2.0.so.0.2600.2)
==    by 0x48CCD1B: ??? (in /usr/lib64/libSDL2_ttf-2.0.so.0.2000.1)
==    by 0x48CD295: ??? (in /usr/lib64/libSDL2_ttf-2.0.so.0.2000.1)
==    by 0x48D7653: ??? (in /usr/lib64/libSDL2_ttf-2.0.so.0.2000.1)
==    by 0x4077C1: Font::write(int, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int) (sdl.cpp:546)
==    by 0x43CD9C: SelectDialog::render() (selectdlg.cpp:210)
==    by 0x43D631: SelectDialog::run() (selectdlg.cpp:312)
==    by 0x4152A7: View::runMenu() (view.cpp:1440)
==    by 0x428E29: main (main.cpp:48)
== 
== Invalid read of size 4
==    at 0x41AFA0: ClientGame::isBrickAtPosition(int, int) (clientgame.h:171)
==    by 0x40C509: View::render() (view.cpp:589)
==    by 0x40B584: View::run() (view.cpp:442)
==    by 0x41537D: View::runMenu() (view.cpp:1447)
==    by 0x428E29: main (main.cpp:48)
==  Address 0xb7305bc is 28 bytes after a block of size 1,136 in arena "client"

[Michael Speck]

I fixed the memory violation, thanks for pointing out. About the premature ending of outbreak: The mini game ends when you loose the ball or there are 7 bricks on the screen. It ends on generating the 7th brick so the counter still shows 6/7 infections. So only if the counter is lower than 6 it really ended prematurely. Can you please check this and send a screenshot if this happens? I tested it and it works for me. I think the congrats message causes some confusion: The mini game is the only level in the special set so when it ends you cleared all levels, hence the message. But I admit this is confusing, so if the set only contains one mini game it now shows "Game Over".

[Oliver Kellogg]

Thanks for your cleanups.
On end, there are 6 bricks left.
However, the Outbreak level still does not feel right, it may end literally just a few seconds after start.
When compared with lbreakout2 (where the level could go on for quite long), the difference I notice is that new bricks appear at a faster rate.
Further, just before the end there is now this valgrind trace:

== Conditional jump or move depends on uninitialised value(s)
==    at 0x4557DB: line_intersect (mathfuncs.c:103)
==    by 0x450FD0: ball_reflect_at_side (balls.c:639)
==    by 0x451A3A: ball_reflect (balls.c:809)
==    by 0x454F22: ball_get_target (balls.c:1600)
==    by 0x452958: balls_update (balls.c:1078)
==    by 0x44516B: game_update (game.c:350)
==    by 0x42A48F: ClientGame::update(unsigned int, double, PaddleInputState&) (clientgame.cpp:263)
==    by 0x40B23F: View::run() (view.cpp:406)
==    by 0x415507: View::runMenu() (view.cpp:1471)
==    by 0x42909B: main (main.cpp:48)

For completeness I am attaching the full valgrind log.

[Michael Speck]

OK, so the game over condition works properly. Yes, I changed the minigame for LBrHD a bit because in the old version you could get stuck endlessly in a wave quite quickly as the "victory condition" was to clear all bricks and the limit of 50 pretty high. So you neither won nor lost. So to speed things up bricks grow faster and the limit is severely reduced. But instead of clearing all bricks you now just need to hold out for a fixed number of bricks to end a wave. So you don't need to "stop the infection" but just keep it at bay for some time. It's a bit harder and plays differently but I like it more this way because you have more progress. So it's more like a tower defence game now: You need to survive for some time without getting overwhelmed.

[Oliver Kellogg]

Just to be clear: The level may spontaneously end after only three or four paddle hits. There is no way whatsoever to survive.

[Michael Speck]

OK, can you please send a screenshot of the game over screen? Because for me it works properly and always exists when the 7th brick is about to appear. Which admittedly happens quite fast unless you start clearing bricks immediately and without ball auto turbo it's quite hard to stay in the game so maybe I need to tweak this a bit.