2020-08-13 16:41 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002595Spring engineGeneralpublic2011-08-04 13:27
Reporterabma 
Assigned Toabma 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusresolvedResolutionfixed 
Product Version 
Target VersionFixed 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.
Checked infolog.txt for Errors
Attached Files

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

-Notes

~0007194

hoijui (reporter)

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.

~0007195

hoijui (reporter)

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

~0007196

abma (administrator)

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)

~0007200

abma (administrator)

both issues solved,thx guys!

(will make a new report for the memleaks)
+Notes

-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
+Issue History