bugLiquid War 6 - Bugs: bug #35016, Segmentation fault

 
 

bug #35016: Segmentation fault

Submitter:  Andrew Engelbrecht <sudoman>
Submitted:  Thu 08 Dec 2011 05:18:20 PM UTC
   
 
Category:  None Severity:  3 - Normal
Status:  Fixed Privacy:  Public
Assigned to:  ufoot Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 24 Dec 2011 02:12:38 AM UTC, comment #11: 

With latest 0.0.13beta, as well as fixing the "map too big" problem and the popping of the window error, I think the ugly segfault has been found (I mispelled < for <= and got an out of bound array error, stupid...)

Christian Mauduit <ufoot>
Group administrator
Tue 13 Dec 2011 08:47:07 PM UTC, comment #10: 

OK, I think I fixed this one. Actually, there might be several causes behind this bug. I was able to reproduce the exact error you had (Application transferred too few scanlines) by trying to play on map "maze". I fixed some bogus way of calling libjpeg (on error, uninitialization would be called without initializing) and for me, it did fix the problem.

Christian Mauduit <ufoot>
Group administrator
Mon 12 Dec 2011 08:05:33 AM UTC, comment #9: 

Thanks for this extensive feedback, the error you get is interesting (about the map being too big). It certainly shouldn't raise a segfault, while the latest developments introduced some map limitations which might be incompatible with some maps in the extra maps package (you're using that aren't you?) there's no reason it crashes the program. I'll take a look into it, one quick-fix is to lower the map below the limit, the other (real) fix is to handle the "this is too big" problem the right way, display an error and let the program keep going.

It's really nice to have such precise bug reports on the current work in progress release, I believe it really helps improving the overall program quality. Thanks.

Have a nice day,

Christian.

PS: noted the fact ulimit works on command-line on your box, for some reason I was never able to achieve that on my boxes, but well, glad to know you can handle it in an easier way than I do.

Christian Mauduit <ufoot>
Group administrator
Sun 11 Dec 2011 01:10:39 PM UTC, comment #8: 

Ok, here's the program I tested. (I used this idea, since it needs to compile.):

#include <stdlib.h>

struct a {
  int b;
};

int main(void)
{
  struct a *inst;
  inst->b = 1;
  return 0;
}

If I run "ulimit -c unlimited" before the test program, I get the core dump, even if I just run ulimit from the command line.

Here are the values of "ulimit -a" before and after running that command:

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

after:
$ ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

I think the issue before was that I wasn't paying attention to the error type that resulted from the crash I was testing with. The actual error before quitting is:

liquidwar6: WARNING! can't load RGBA JPEG file "/usr/local/share/liquidwar6-0.0.12beta/map/extra/ufoot/concept/maze/texture.jpeg", it is too big (size=3840x2400 max=3000x2000)
Application transferred too few scanlines


(sorry for so many different issues under one bug, and thanks for the guidance :)

Andrew Engelbrecht <sudoman>
Sun 11 Dec 2011 06:33:50 AM UTC, comment #7: 

For some reason (maybe trying to be end-user friendly and avoid multiplication of core files on hard drives) recent GNU/Linux distributions systematically disable core dumps. You're right that "ulimit -c unlimited" is the answer but my experience is that it has to be in the shell startup files (typically $HOME/.profile or $HOME/.bash_profile or even /etc/profile). Edit one of these files, then compile and run a simple program such as

#include <stdlib>

int main(int argc, char* argv[])
{
    void *ptr=0;

    (*ptr)++;
}

The core should, as you guessed, appear in the directory where you started the program, it's straightforward.

Out of curiosity, what is the output of "ulimit -c" and "ulimit -a" on your system (after and before you type ulimit -c unlimited).

Thanks for your patience, and have a nice day,

Christian.

Christian Mauduit <ufoot>
Group administrator
Sun 11 Dec 2011 12:20:08 AM UTC, comment #6: 

ok, i've tried using that command line option: the screen returns to normal after a segfault.

However, I cannot figure out how to get a core dump. (I am not using the "make dist" and "make deb" commands here, just regular "make" and "make install".) I ran "ulimit -c unlimited" before running liquidwar6, but I cannot find an appropriate file named "core" on my entire system.

$ cat /proc/sys/kernel/core_pattern
core

I'm guessing I should be getting a file in the directory that liquid war 6 is launched from?

-Andrew

Andrew Engelbrecht <sudoman>
Sat 10 Dec 2011 10:27:09 PM UTC, comment #5: 

mmm, I guess you really should run the latest snapshot with

--trap-errors=false

(it's the default in latest releases) and see what gdb can tell you post-mortem (something like "gdb -c code ./liquidwar6" and then "bt".

From what I see in this backtrace the segfault appears somewhere in the OpenGL stack when drawing stuff, however I can't figure that way exactly where it comes from. The window you get is a trade-off I decided to set up to be sure to get minimum feedback when a segfault occurs but as a technical savvy user you can get much more information from standard gdb and backtraces done from core files.

I acknowledge I haven't run valgrind for a bunch of time against the latest code, might reveal weird things, it's usually a nice bug finder assistant.

Have a nice day,

Christian.

Christian Mauduit <ufoot>
Group administrator
Sat 10 Dec 2011 09:54:45 PM UTC, comment #4: 

Here's another backtrace:

liquidwar6(lw6sys_signal_segv_handler+0x61) [0x486921], /lib/x86_64-linux-gnu/libc.so.6(+0x33d80) [0x7f06526c2d80], /lib/x86_64-linux-gnu/libc.so.6(+0x79e39) [0x7f0652708e39], /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x6e) [0x7f065270b31e], /lib/x86_64-linux-gnu/libdrm_intel.so.1(+0x6213) [0x7f064827c213], /lib/x86_64-linux-gnu/libdrm_intel.so.1(+0x634d) [0x7f064827c34d], /usr/lib/dri/i965_dri.so(brw_upload_state+0x8e) [0x7f0648c1317e], /usr/lib/dri/i965_dri.so(brw_draw_prims+0x572) [0x7f0648c020f2], /usr/lib/dri/libdricore.so(vbo_exec_vtx_flush+0x560) [0x7f0648889100], /usr/lib/dri/libdricore.so(vbo_exec_FlushVertices_internal+0x8c) [0x7f0648886e2c], /usr/lib/dri/libdricore.so(vbo_exec_FlushVertices+0x4a) [0x7f064888702a], /usr/lib/dri/libdricore.so(_mesa_MatrixMode+0x11e) [0x7f064880bf5e], liquidwar6() [0x4aee76], liquidwar6() [0x4bd79d], liquidwar6() [0x496f32], liquidwar6() [0x4966c4], liquidwar6(_lw6dsp_thread_func+0x697) [0x457dd7], liquidwar6() [0x422f66], /lib/x86_64-linux-gnu/libpthread.so.0(+0x6d8c) [0x7f0652c37d8c], /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f065277504d]

Thanks for this awesome game :)
-Andrew

Andrew Engelbrecht <sudoman>
Thu 08 Dec 2011 09:32:19 PM UTC, comment #3: 

OK, this is the very code I'm hacking on these days. BTW there's an error (SIGSEGV) catcher in the snapshot you tested, which does not help when using gdb. I disabled this in next release, by default, on GNU/Linux systems and any UNIXish system, the bet is that on those systems users are savvy enough to run gdb themselves and send the information.

I'm trying to fix that bug. Stay tuned.

Have a nice day,

Christian.

Christian Mauduit <ufoot>
Group administrator
Thu 08 Dec 2011 05:58:25 PM UTC, comment #2: 

here is the backtrace.txt file contents:

liquidwar6(lw6sys_signal_segv_handler+0x61) [0x4978e1], /lib/x86_64-linux-gnu/libc.so.6(+0x33d80) [0x7f604f983d80], /usr/local/lib/liquidwar6-0.0.12beta/gfx/libmod_gl-0.0.12beta.so(_mod_gl_menu_cylinder_display_meta+0x51) [0x7f604b2732a1], /usr/local/lib/liquidwar6-0.0.12beta/gfx/libmod_gl-0.0.12beta.so(+0xd462) [0x7f604b264462], liquidwar6(lw6gfx_display+0x104) [0x4a7684], liquidwar6(_lw6dsp_thread_func+0x697) [0x468057], liquidwar6() [0x435876], /lib/x86_64-linux-gnu/libpthread.so.0(+0x6d8c) [0x7f6050306d8c], /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f604fa3604d]

Andrew Engelbrecht <sudoman>
Thu 08 Dec 2011 05:20:14 PM UTC, comment #1: 

by the way, the game freezed a few times (every time) after a couple of minutes of play in the sub flower map.

Andrew Engelbrecht <sudoman>
Thu 08 Dec 2011 05:18:20 PM UTC, original submission:  

Using the latest git revision on Trisquel 5.0 64 bit intel, I get a segfault. The graphics freeze and the music continues to play. I can switch to a tty and kill liquidwar6 with the -9 option. This was the output of running liquidwar6 from the command line:

liquidwar6: v0.0.12beta "Aguirre" #2905 (Dec  8 2011) linux-gnu/x86_64
liquidwar6: running "/usr/local/share/liquidwar6-0.0.12beta/script/liquidwar6.scm"
liquidwar6: log file "/home/sudoman/.liquidwar6/log.csv"
liquidwar6: loaded module "/usr/local/lib/liquidwar6-0.0.12beta/gfx/libmod_gl-0.0.12beta.so"
liquidwar6: started node "http://192.168.1.104:8056/"
liquidwar6: WARNING! team color index -1 isn't valid
liquidwar6: ERROR! Segmentation fault
Killed


(there doesn't see to be anything relevant in the log file.)

Andrew Engelbrecht <sudoman>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ufoot (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-01-05 ufoot Open/ClosedOpen Closed
    2011-12-18 ufoot StatusReady For Test Fixed
    2011-12-13 ufoot StatusIn Progress Ready For Test
    2011-12-08 ufoot StatusNone In Progress
        Assigned toNone ufoot

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code