Invalid pointer detection by glibc #15
Comments
|
I'll add more of them whenever they come out. |
|
I don't have them unfortunately but for memory, there is sometimes a leak/memory corruption? in the audio manager and in the script manager. |
|
Invalid pointer bit about Audio Managerment from Shirish: $ ./src/valyriatear |
|
Ok, I made two patches hopefully dealing with the two invalid pointer detection we have listed so far. |
|
Here's another one, dunno if it's the same :-
This is with the latest git master. Kept on the next forest part.```` |
|
Hi, Hmm, I'll need the commit point.
|
|
Oops, sorry this is where it happened.
|
|
Another one, dunno if I'm recycling the same or not :-
This is at latest git head :-
Again this was when pressing the Quit game by pressing 'ESC' in-game and then selecting quit game from the three options given. This was during a new battle which had just commenced. |
|
Hmm, interesting. With the logging added, I might have the guilty one. |
|
In the case of the confirm audio manager crash at quit, I do think it's linked to the sound owning management (that I'll remove completely to let the audio cache do the job. In the case of the script engine crash, I read a lot about luabind objects and It seems that using pointers for that might be a cause of a memory corruption. I've done changes in the ScriptedEvents and ScriptedSpriteEvent the game is using a lot and we'll see if things improve here. |
|
well, seems it didn't improve things. I was being chased around by couple of monsters and was about to enter battle when I quit when I got the invalid pointer bug again. This is from the latest git head |
|
The fact is that I still didn't work on that. And indeed, the confirm sound seems to be involved. |
|
Understood, this is with the latest git, played for about 20 odd minutes and saved and nice. It was only when quitting that I got hit with it. There was a typo in the evade raise status effect leading to a crash, I had to remove the paralysis effect of the stun strike since |
|
Hmm, this one is new AFAIK.
Err, no, not when using that one. Yet, consider all the applications you're using even on closed sources software and OS being full of holes waiting to be discovered. Allacrost/Valyria Tear have their own but I sincerely guess a true hacker would prefer using a program a wide variety of people is using rather than a mere demo game. I wonder what computering level you personally have and I don't want to judge somebody on that, but sincerely you can't ask me to worry about potential attacks. |
|
@Bertram25 I think you misunderstood my point/issue. Lemme ask another way, does it help you anyway if I provide/don't provide memory locations when a crash happens? If it doesn't help you other than just for the sake of completeness, then wouldn't provide the memory map unless asked. Shouldn't the backtrace have enough info. as to the nature of the crash ? Your point is fair that a potential attacker would probably use a mainstream program and could probably use many ways if they wanted to get onto my system. Looking forward to updates. |
|
Ah, ok, my bad then. As the pointer values are different on each crashes because the binary changes each time (new commits and recompilation) and because I didn't setup some advanced tools for that yet, (I should look again at how, first, anyway...), I indeed only need the backtraces are for the last statement calls, and then work around that, which has paid off until now, even little by little. If you've got some good tutorial about reusing such other values, btw, I'll use them. :) |
|
Latest invalid pointer bug should dealt with: |
|
Should be partly dealt with, with this one: Unfortunately, crashes aren't gone since there is still something badly removed sometimes. And I don't have a clue for now. |
This will help fix issue #15 I also added the try/catch useful to get feedback for bugs in lua scripts.
|
An helper for the crash related to lua_close() call Certain luabind::object might not destructed before the lua_close invocation is done, which should be the case to avoid a crash resembling the one we have. (I'm not speaking of audio crashes). |
|
Also, temp object pointers in lua function calls shouldn't be used as said here: I'll check that also in my scripts. |
…certain crash cases. I did that with the hope that it will prevent certain crashes due to luabind::object not destroyed when the lua state is closed, according to: http://sylefeb.blogspot.ch/2010/08/luabind-global-tables-of-classes.html Related to #15.
|
Just curious, have you tried running hte binary on Valgrind? Its a linux-only tool (AFAIK) but its phenominal for finding bad frees / memory leaks. you're gonna get some MAJOR slowdown, but it may be worth it... |
Yep, I have used valgrind several times, including on Valyria tear, as memroy analysis tool but also as a call catcher one or two time.
I also notably used gprof for straighter profiling, which already helped here. :)
Let's say that yes VT isn't mem leak free at all, but certainly that is a task that can wait for now.
Thanks for pointing out anyway.
Regards,
—
|
|
maybe a new one. It gives more info. than before for sure. This is with the latest git commit. ~/games/valyriatear$ ./src/valyriatear See the error message it gave :- ~/games/valyriatear$ ./src/valyriatear Dunno if this is another error or not. If it's another error please lemme know. I am sending the save file to you . This is after saving when quitting the game. |
|
The warning is about an event play at the beginning of a dialogue, which is played twice when you pass the dialogue fast. We've been seeing this several times already and I used to fix this through scripting adaptations, but I'll open another issue now I've found the actual cause of this. The crash at quit belongs to #15. Thanks for the info, I'll close this one and open a new issue about the warning. |
|
arf, 'm sleepy, didn't see it was th #15, I've reopened it. |
|
Replaced by #134 |
From Shirish:
~/games/valyriatear$ ./src/valyriatear
*** glibc detected *** ./src/valyriatear: free(): invalid pointer:
0x00007f692c554490 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x75b76)[0x7f693d745b76]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7f693d74a8ac]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0x1605e4)[0x7f6930e345e4]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0x160ba8)[0x7f6930e34ba8]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0x1d794d)[0x7f6930eab94d]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0x1b8cc5)[0x7f6930e8ccc5]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0x1b8cad)[0x7f6930e8ccad]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0xdcab7)[0x7f6930db0ab7]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0xdce47)[0x7f6930db0e47]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0xdcef9)[0x7f6930db0ef9]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0xdcc47)[0x7f6930db0c47]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0x151dea)[0x7f6930e25dea]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0x151eee)[0x7f6930e25eee]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0x14b9e5)[0x7f6930e1f9e5]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0x78344)[0x7f6930d4c344]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0x53252)[0x7f6930d27252]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0x33033)[0x7f6930d07033]
/usr/lib/x86_64-linux-gnu/libGL.so.1(+0x4606c)[0x7f693f8b506c]
/usr/lib/x86_64-linux-gnu/libGL.so.1(glXDestroyContext+0x121)[0x7f693f88e5e1]
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0(+0x3c9b2)[0x7f69403b99b2]
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0(+0x4093c)[0x7f69403bd93c]
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0(+0x40b25)[0x7f69403bdb25]
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0(SDL_VideoQuit+0x4e)[0x7f69403afe4e]
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0(SDL_QuitSubSystem+0x55)[0x7f6940389755]
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0(SDL_Quit+0xe)[0x7f69403897fe]
/lib/x86_64-linux-gnu/libc.so.6(+0x36df2)[0x7f693d706df2]
/lib/x86_64-linux-gnu/libc.so.6(+0x36e45)[0x7f693d706e45]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x104)[0x7f693d6eeeb4]
I can't really know where that one comes from.
The text was updated successfully, but these errors were encountered: