Most of the time briquolo runs just fine. However, sometimes it
crashes with a segfault.

I rebuild briquolo with DEB_BUILD_OPTIONS="noopt" set and ran it under gdb until it
crashed. Unfortunately, X was blocked from input (both mouse and
keyboard) while the crashed briquolo was present, so I killed it frum
the console (not the gdb process, however).

In gdb I had the following output:
Program received signal SIGSEGV, Segmentation fault.
TableauJeu::Maj (this=0x392b83a6700) at TableauJeu.cpp:336
336                  detruire=collision.ResponsableCollision->Toucher(*itBalle, collision.TempsCollision);
(gdb) bt full
#0  TableauJeu::Maj (this=0x392b83a6700) at TableauJeu.cpp:336
        detruire = false
        collision = {VitesseX = 12.129584081744198, VitesseY = -33.20953567084883, PositionX = 0.751, PositionY = 3.0671900023491165,
          TempsCollision = <optimized out>, AddFacteurCollision = <optimized out>, ResponsableCollision = <optimized out>}
        collisionTemps = <error reading variable collisionTemps (Cannot access memory at address 0x3e50170d0b0)>
        collisionElementTableau = true
        remainingTime = <optimized out>
        offy = <optimized out>
        itBalle = {_M_node = 0x392b87b87c0}
        setBonusADetruire = <error reading variable setBonusADetruire (Cannot access memory at address 0x3e50170d080)>
        itBonus = <optimized out>
        offx = <optimized out>
        nbElemReste = <optimized out>
        setBalleADetruire = <error reading variable setBalleADetruire (Cannot access memory at address 0x3e50170d050)>
#1  0x0000000000412678 in CasseBrique::_Idle (this=0x3e50170d250, this@entry=<error reading variable: Cannot access memory at address 0x3e50170d1e8>)
    at CasseBrique.cpp:254
        ch = <error reading variable ch (Cannot access memory at address 0x3e50170d160)>

As this is my first crash under gdb, I cannot say of course if the
same positions hold for the other crashes, too.

If you need further information, do no hesitate to contact me.

Hello,
just as an additional note: After sending I had a another crash at the
same position in the source code (interestingly also the same level).

Greetings

            Helge

Hi Helge,

thanks for the report. Could you describe what you did exactly during
the game when this crash occurred, e.g. moving the mouse to a certain
position, destroying a brick or switching to another camera perspective?

In which level did the crash happen?

Can you reproduce the crash with one of Debian's stock kernels? (I see
that you currently use a custom one)

It would be great if you could build the game with nostrip too.

DEB_BUILD_OPTIONS="noopt nostrip"

Best,

Markus

...and please attach the complete gdb.log. You can activate logging with

set logging on

in gdb.

Thank you

Hello Markus,

One of the first two. I can *try* to determine it further, but it is a
faced paced game. Previously I only used the cursor keys, but today I
was actually using the mouse.

Those two I saw today under gdb were actually in the "Neue Level" and
right the first one.

Sorry, thats beyond the effort I'm willing to take to debug a game. My machines
currently run this kernel exclusively; but I might have access to a
machine with a stock kernel, I'll check.
root@sneo:~# file /usr/games/briquolo
/usr/games/briquolo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26,
BuildID[sha1]=0x2dba9baf45b8cdb371e8397d7a9cfc169844ebd4, not stripped

Nevertheless, the build is on the way as I type.

I'll report the next crash with this binary after it happend. (Might
not be today, sorry).

And thanks for your ultrafast reply.

Greetings

             Helge

On 24.05.2014 15:23, Helge Kreutzmann wrote:
[...]

Understood. However your custom kernel might be exactly the reason why
you experience the crash and I have to make sure that we both don't hunt
a bogus bug here.

That's strange. I have to use DEB_BUILD_OPTIONS="noopt nostrip". Just
using "noopt" strips the binary from all debugging symbols. You can
verify this in gdb. If you see a line like

Reading symbols from /usr/games/briquolo

you binary is not stripped and everything is fine.

No problem. Have a nice weekend

Markus

Hello Markus,

I understand your point. I will try to get access to a "plain"
machine.

Yes I see this (with the rebuild one, though).

Made it crash again. The ball was at the hight of the paddle
(actually, between the paddle and the wall) when it happend. And yes,
I turn on logging next time (tomorrow if possible), the crash happend
again at the same place in the code.

The level was in the "Neue Level" around 8 I believe.

Inform you when I have the next crash with logging.

Greetings

             Helge

On 24.05.2014 20:31, Helge Kreutzmann wrote:
[...]

Hi Helge,

I just saw the bug in two different levels. Seems to be rather random.
Strange, I was always under the impression that briquolo was one of the
more stable games. It appears this is some kind of memory issue or has
something to do with uninitialized values and I have to use valgrind to
dig deeper into the problem. This will probably take some time. Thanks
for reporting. I am tagging the bug report as confirmed.

Regards,

Markus

Hello Markus,

Thanks for confirming.

Then just for the record here are the gdb.txt from the latest crash as
well as all gdb output. It happend in a high level, again the ball was
left to the paddle (between the paddle and the wall, actually).

Then I play briquolo now again as usual, without gdb and such.

Greetings

             Helge

The issue seems to be uninitialized values when the instance of Balle is
created in TableauJeu.cpp:115

Balle * balle=new Balle;

I don't understand why the default constructor does not initialize the
object automatically. If someone with better C++ knowledge knows the
answer I gladly accept some help here.

For debugging compile briquolo with noopt nostrip and run valgrind with
--track-origins=yes like

valgrind --leak-check=full --track-origins=yes --log-file=valgrind.log
briquolo

I reported this bug upstream but I received no reply.

Markus