View Issue Details

IDProjectCategoryView StatusLast Update
0002595Spring engineGeneralpublic2011-08-04 13:27
Reporterabma Assigned Toabma  
PrioritynormalSeveritymajorReproducibilityhave not tried
Status resolvedResolutionfixed 
Fixed in Version83.0 
Summary0002595: (master) valgrind log complains about: "Invalid read of size 4 in DamageArray::GetDefaultDamage() const (DamageArray.h:47)"
Descriptioni guess this function is called when the object is already desctructed?
Additional Informationalso see attached valgrind.log. its currently incomplete, its running since about 3hours or so... will attach complete file when its finished.

run with:
valgrind --trace-children=yes --leak-check=full --log-file=valgrind.log spring-headless aitest.txt

TagsNo tags attached.
Attached Files
valgrind.log (Attachment missing)
valgrind-full.log (Attachment missing)
Checked infolog.txt for Errors

Relationships

has duplicate 0001953 resolvedabma valgrind log 
related to 0002596 resolvedabma (master) memleaks found by valgrind 

Activities

hoijui

2011-08-02 15:03

reporter   ~0007194

Last edited: 2011-08-02 15:04

DamageArray related problems are fixed in these commits:
https://github.com/spring/spring/commit/b6ea4915c9ab365910ba12501f988034f5a5f1ec
https://github.com/spring/spring/commit/46a073e78f5c3092b0a59cb05e10adb5732ce066

good find abma!! :-)
(and yes you were right, DamageArray was used when it was already freed)

not really important:
about all the ones with inflateReset2 in zlib:
it is a zlib error, as can be seen here:
http://www.zlib.net/ChangeLog.txt
fixed in zlib 1.2.3.7 (24 Jan 2010)

you may want to use valgrind suppressions for stuff that happens in the libraries (like opengl, devil (stuff starting with il*), zlib and the like)), though the suppression system is not so straight forward, and badly documented. maybe there are useful GUI tools for that.

hoijui

2011-08-02 15:59

reporter   ~0007195

i tested with cppcheck from github, and it is not able to detect the issue we had here with DamageArray. so i made a simple test-case and reported it as a feature request:
https://sourceforge.net/apps/trac/cppcheck/ticket/2957

abma

2011-08-02 17:38

administrator   ~0007196

Last edited: 2011-08-02 17:42

then one issue is left: (others seem to be "only" mem-leaks)

==4052== Invalid read of size 8
==4052== at 0x6B64337: __GI___strncasecmp_l (strcmp.S:215)
==4052== by 0x6B1AFAE: ____strtod_l_internal (strtod_l.c:577)
==4052== by 0x115954F: luaO_str2d(char const*, float*) (lobject.cpp:92)
==4052== by 0x11652E3: luaV_tonumber(lua_TValue const*, lua_TValue*) (lvm.cpp:41)
==4052== by 0x1149BA6: lua_isnumber(lua_State*, int) (lapi.cpp:264)
==4052== by 0xBD4F20: CLuaHandle::SendToUnsynced(lua_State*) (LuaHandle.cpp:337)
==4052== by 0x1153588: luaD_precall(lua_State*, lua_TValue*, int) (ldo.cpp:319)
==4052== by 0x116824C: luaV_execute(lua_State*, int) (lvm.cpp:612)
==4052== by 0x115385C: luaD_call(lua_State*, lua_TValue*, int) (ldo.cpp:377)
==4052== by 0x114B209: f_call(lua_State*, void*) (lapi.cpp:812)
==4052== by 0x11528BC: luaD_rawrunprotected(lua_State*, void (*)(lua_State*, void*), void*) (ldo.cpp:116)
==4052== by 0x1153C72: luaD_pcall(lua_State*, void (*)(lua_State*, void*), void*, long, long) (ldo.cpp:463)
==4052== Address 0x2104f0a0 is 32 bytes inside a block of size 38 alloc'd
==4052== at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
==4052== by 0x4C29026: realloc (vg_replace_malloc.c:525)
==4052== by 0x114D60B: l_alloc(void*, void*, unsigned long, unsigned long) (lauxlib.cpp:635)
==4052== by 0x1159366: luaM_realloc_(lua_State*, void*, unsigned long, unsigned long) (lmem.cpp:82)
==4052== by 0x115EFB5: newlstr(lua_State*, char const*, unsigned long, unsigned int) (lstring.cpp:56)
==4052== by 0x115F33F: luaS_newlstr(lua_State*, char const*, unsigned long) (lstring.cpp:122)
==4052== by 0x116BBC9: luaX_newstring(LexState*, char const*, unsigned long) (llex.cpp:119)
==4052== by 0x116CA8F: read_string(LexState*, int, SemInfo*) (llex.cpp:330)
==4052== by 0x116D056: llex(LexState*, SemInfo*) (llex.cpp:393)
==4052== by 0x116D3AF: luaX_next(LexState*) (llex.cpp:455)
==4052== by 0x115C7CB: funcargs(LexState*, expdesc*) (lparser.cpp:618)
==4052== by 0x115CB09: primaryexp(LexState*, expdesc*) (lparser.cpp:718)

shouldn't it be an < instead of <= https://github.com/spring/spring/blob/master/rts/Lua/LuaHandle.cpp#L335 [^] ?



(added full-valgrind.log)

abma

2011-08-02 20:00

administrator   ~0007200

both issues solved,thx guys!

(will make a new report for the memleaks)

Issue History

Date Modified Username Field Change
2011-08-02 12:26 abma New Issue
2011-08-02 12:26 abma File Added: valgrind.log
2011-08-02 12:26 abma Relationship added related to 0001953
2011-08-02 14:48 abma Relationship replaced has duplicate 0001953
2011-08-02 15:03 hoijui Note Added: 0007194
2011-08-02 15:04 hoijui Note Edited: 0007194
2011-08-02 15:59 hoijui Note Added: 0007195
2011-08-02 17:30 abma File Added: valgrind-full.log
2011-08-02 17:38 abma Note Added: 0007196
2011-08-02 17:38 abma Note Edited: 0007196
2011-08-02 17:41 abma Note Edited: 0007196
2011-08-02 17:42 abma Note Edited: 0007196
2011-08-02 18:48 abma Additional Information Updated
2011-08-02 20:00 abma Note Added: 0007200
2011-08-02 20:00 abma Status new => resolved
2011-08-02 20:00 abma Fixed in Version => 0.83.0
2011-08-02 20:00 abma Resolution open => fixed
2011-08-02 20:00 abma Assigned To => abma
2011-08-04 11:27 abma Relationship added related to 0002596
2011-08-04 13:27 abma File Added: valgrind-verbose.7z
2011-08-04 13:27 abma File Deleted: valgrind-verbose.7z