Segfault on gcw

[DavidKnight247]

I would lke to get cdogs to a state where it can be placed on the official gcw repository. In order for this to happen, it must be crash free ;)

I have noticed that at least on the gcw the game occasionally crashes during campaigns seemingly when there are a lot of actors and/or objects present and when you are in an open area.

It is particularly a problem in Markeroo/Hoppin' Flowers level 2 (password nsweef) where it crashes consistently within 10 seconds or so. Counting the red/green arrows at this time there are 3 actors on screen and 17 off screen identified by their arrows, 7 green and the rest red.
I ran top from the console. Cpu and mem usage appears normal just before a crash (around 50-95% and 22% respectively).

It also occurs less often on the first mission, I have attempted to play the same mission on the windows build and it crashes within seconds so it may be a common bug not related to the gcw platform.

gdb output:

Starting program: /media/data/local/home/cdogsbuilds/cdogsdebugbuild/cdogs-sdl --debug=2
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0042cf08 in ActorAdd (c=0x80000, p=0x0)
at /home/david/cdogs-sdl/src/cdogs/actors.c:1094
1094 /home/david/cdogs-sdl/src/cdogs/actors.c: No such file or directory.
#0 0x0042cf08 in ActorAdd (c=0x80000, p=0x0)

at /home/david/cdogs-sdl/src/cdogs/actors.c:1094

#1 0x00430654 in CommandBadGuys (ticks=1)

at /home/david/cdogs-sdl/src/cdogs/ai.c:548

#2 0x00419834 in RunGameUpdate (data=0x7fcc8c04)

at /home/david/cdogs-sdl/src/game.c:563

#3 0x0045d9d4 in GameLoop (data=0x7fcc8de0)

at /home/david/cdogs-sdl/src/cdogs/game_loop.c:91

#4 0x004191d8 in RunGame (m=0x55e894 , map=0x55f01c )

at /home/david/cdogs-sdl/src/game.c:450

#5 0x00414094 in Game (graphics=0x55efc0 ,

co=0x55e8e0 <gCampaign>) at /home/david/cdogs-sdl/src/cdogs.c:295

#6 0x00414570 in Campaign (graphics=0x55efc0 ,

co=0x55e8e0 <gCampaign>) at /home/david/cdogs-sdl/src/cdogs.c:376

#7 0x00414c50 in MainLoop (creditsDisplayer=0x7fcc9064, campaigns=0x7fcc9084)

at /home/david/cdogs-sdl/src/cdogs.c:478

#8 0x004161e4 in main (argc=2, argv=0x7fccd294)

at /home/david/cdogs-sdl/src/cdogs.c:830

[Current thread is 1 (Thread 0x77661000 (LWP 652))]
[New Thread 0x75bde500 (LWP 657)]
[New Thread 0x7646f500 (LWP 656)]
[New Thread 0x770e6500 (LWP 655)]
Id Target Id Frame
4 Thread 0x770e6500 (LWP 655) "cdogs-sdl" 0x7747e750 in nanosleep ()
from /lib/libc.so.0
3 Thread 0x7646f500 (LWP 656) "cdogs-sdl" 0x7747e750 in nanosleep ()
from /lib/libc.so.0
2 Thread 0x75bde500 (LWP 657) "cdogs-sdl" 0x775b4ac8 in pthread_cond_wait
() from /lib/libpthread.so.0

• 1 Thread 0x77661000 (LWP 652) "cdogs-sdl" 0x0042cf08 in ActorAdd (
  c=0x80000, p=0x0) at /home/david/cdogs-sdl/src/cdogs/actors.c:1094
  [Switching to thread 1 (Thread 0x77661000 (LWP 652))]
  #0 0x0042cf08 in ActorAdd (c=0x80000, p=0x0)

  at /home/david/cdogs-sdl/src/cdogs/actors.c:1094
  1094 in /home/david/cdogs-sdl/src/cdogs/actors.c
  A debugging session is active.

  Inferior 1 [process 652] will be killed.

Quit anyway? (y or n)

[cxong]

I see this bug exists in the Windows 0.5.6 release but I cannot reproduce it under Visual Studio in the current revision. Perhaps it's something exposed by GCC? I will try again later.

[DavidKnight247]

I just quickly downloaded latest source and checked again, my previous
build is a few days old. No change, still the same behaviour.

On Fri, Sep 5, 2014 at 1:22 AM, Cong notifications@github.com wrote:

I see this bug exists in the Windows 0.5.6 release but I cannot reproduce
it under Visual Studio in the current revision. Perhaps it's something
exposed by GCC? I will try again later.

—
Reply to this email directly or view it on GitHub
#302 (comment).

[cxong]

Unfortunately I just can't reproduce this; I've tried OS X Xcode (clang), Mint 16 GCC and MinGW, in all cases the campaign (Markeroo/Hoppin' Flowers (hard) level 2 (password nsweef)) works fine and I can complete it without crashes.

Could you please be very specific about how it can be reproduced? What video resolution, how many players did you play with etc.

[cxong]

@DavidKnight247 here's one more thing you could try; run with the argument --debug 1 or --debug 2; when the game crashes note what the standard out/error are, and copy them here.

[DavidKnight247]

Video resolution 320x240x1, one player, default character (Jones), weapons
shotgun, machine gun and shrapnel bomb. If I start the level and do nothing
it crashes 9/10 times within 10 seconds or so. The other time it doesn't,
but when I start moving around it then crashes. I have yet to complete the
level.
gdb always shows CREALLOC in ActorAdd in actors.c line 1096 (based on
current version compiled today) in CommandBadGuys. I tested with other busy
levels (the techdemo level with lots of baddies springs to mind, lots of
chugging but no crashes). Is there a particular actor/weapon combination
specific to a single actor on this level perhaps? Every time it crashes on
a CREALLOC call in actors.c. The line is
I don't know enough about this topic but is there perhaps a finite limit on
memory set for actors/objects/whatever, perhaps related to free memory? The
GCW only has 512mb, as I said memory usage seems to be consistently 22% or
so when monitored with top.

I'd suggest if you cannot replicate I would be happy to dive in, I reckon
it's the best way to learn and with a few debug lines I'll soon figure out
the problem ;). Unfortunately owing to a conference I have little free time
from now until Tuesday.

On Fri, Sep 5, 2014 at 3:18 PM, Cong notifications@github.com wrote:

Unfortunately I just can't reproduce this; I've tried OS X Xcode (clang),
Mint 16 GCC and MinGW, in all cases the campaign (Markeroo/Hoppin' Flowers
(hard) level 2 (password nsweef)) works fine and I can complete it without
crashes.

Could you please be very specific about how it can be reproduced? What
video resolution, how many players did you play with etc.

—
Reply to this email directly or view it on GitHub
#302 (comment).

[cxong]

Well I've finally gotten around to building and testing on GCW-Zero myself, and I cannot reproduce this. Given that this issue exists in 0.5.6 but also fails to reproduce on Windows in recent revisions, I think this must have been accidentally fixed some time since.

[DavidKnight247]

Great!

On Wed, Oct 29, 2014 at 11:28 AM, Cong notifications@github.com wrote:

Well I've finally gotten around to building and testing on GCW-Zero
myself, and I cannot reproduce this. Given that this issue exists in 0.5.6
but also fails to reproduce on Windows in recent revisions, I think this
must have been accidentally fixed some time since.

—
Reply to this email directly or view it on GitHub
#302 (comment).