#6316 closed defect (outdated)
Segmentation fault on startup on Ubuntu 12.04 precise armv7l
| Reported by: | SF/katiahayati | Owned by: | csnover |
|---|---|---|---|
| Priority: | normal | Component: | Port: Linux |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
This problem is present for me when I compile git master on Ubuntu precise on an armv7l processor (Samsung Chromebook running crouton). The valgrind output is:
----------- hayati@localhost:~/git/scummvm$ valgrind ./scummvm ==3734== Memcheck, a memory error detector ==3734== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==3734== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==3734== Command: ./scummvm ==3734== WARNING: SDL mixer output buffer size: 1024 differs from desired: 2048! ==3734== Syscall param writev(vector[...]) points to uninitialised byte(s) ==3734== at 0x4B02276: __libc_do_syscall (libc-do-syscall.S:47) ==3734== by 0x4B77143: writev (writev.c:56) ==3734== by 0x4E9DF4D: ??? (in /usr/lib/arm-linux-gnueabihf/libxcb.so.1.1.0) ==3734== Address 0x52f63f3 is 19 bytes inside a block of size 16,384 alloc'd ==3734== at 0x482C778: calloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so) ==3734== WARNING: Could not find theme 'scummmodern' falling back to builtin! ==3734== Invalid read of size 4 ==3734== at 0x22F8EA: scale3x(void*, unsigned int, void const*, unsigned int, unsigned int, unsigned int, unsigned int) (scalebit.cpp:149) ==3734== Address 0x68bb60cf is not stack'd, malloc'd or (recently) free'd ==3734== ==3734== ==3734== HEAP SUMMARY: ==3734== in use at exit: 3,281,702 bytes in 2,698 blocks ==3734== total heap usage: 17,923 allocs, 15,225 frees, 6,104,089 bytes allocated ==3734== ==3734== LEAK SUMMARY: ==3734== definitely lost: 24 bytes in 3 blocks ==3734== indirectly lost: 104 bytes in 4 blocks ==3734== possibly lost: 12 bytes in 1 blocks ==3734== still reachable: 3,281,562 bytes in 2,690 blocks ==3734== suppressed: 0 bytes in 0 blocks ==3734== Rerun with --leak-check=full to see details of leaked memory ==3734== ==3734== For counts of detected and suppressed errors, rerun with: -v ==3734== Use --track-origins=yes to see where uninitialised values come from ==3734== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 1) Segmentation fault (core dumped) ----------------
This problem also occurs when I use the precompiled binary via apt-get.
Ticket imported from: #3612696. Ticket imported from: bugs/6316.
Change History (31)
comment:1 by , 12 years ago
comment:3 by , 12 years ago
Not sure if this is relevant, but I have been trying to get debug information from a guy on the forums with a similar issue compiling on an ARM board... FYI: http://forums.scummvm.org/viewtopic.php?t=12345
comment:4 by , 12 years ago
Hard to say, since unfortunately any actual debugging information in that forum thread seems to have been lost from cpaste.org. (Also I am unsure why you are focussing on theme and file issues there, but maybe the disappeared debugging info pointed at that?)
comment:5 by , 12 years ago
Hi fuzzie, yes, I tried forcing a 1x shader (and every other shader option), compiling with shaders disabled, and compiling with --disable-nasm.
comment:7 by , 12 years ago
katiahayati: Thank you for this bug report... Since we have another report of oddities from ARM builds and you seem to have a good grasp on coding and valgrind, could you please provide some further debugging information.
Specifically, could you try with the latest git master, doing a compile with "./configure --disable-nasm --disable-scalers --disable-hq-scalers && make clean && make" and then test... If this still crashes, can you provide another valgrind trace please as this can't be in scale3x if the scalers are disabled... so something very hinky is going on.
Apart from this, could you indicate your SDL library build version and configuration i.e. what SDL_VIDEO_DRIVER are you using i.e. fbdev or X11, and any other pertient to video output information... I am concentrating on video as this looks like the scaler is accessing outside the video buffer size prompting a segfault... This may be occuring if the screen size is vey large and causing some variable to wrap... but we need debug data to work out what is going on! :) Thanks in advance.
comment:8 by , 12 years ago
tdhs: thank you! So I recompiled scummvm from master with the config options you gave. Now the GUI loads briefly (blank window) then crashes with a floating point error. Here is the valgrind output:
hayati@localhost:~/git/scummvm$ valgrind ./scummvm ==29207== Memcheck, a memory error detector ==29207== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==29207== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==29207== Command: ./scummvm ==29207== WARNING: SDL mixer output buffer size: 1024 differs from desired: 2048! ==29207== Syscall param writev(vector[...]) points to uninitialised byte(s) ==29207== at 0x4B1E276: __libc_do_syscall (libc-do-syscall.S:47) ==29207== by 0x4B93143: writev (writev.c:56) ==29207== by 0x4D93F4D: ??? (in /usr/lib/arm-linux-gnueabihf/libxcb.so.1.1.0) ==29207== Address 0x4e0603b is 19 bytes inside a block of size 16,384 alloc'd ==29207== at 0x482C778: calloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so) ==29207== ==29207== ==29207== HEAP SUMMARY: ==29207== in use at exit: 100,414 bytes in 1,118 blocks ==29207== total heap usage: 14,963 allocs, 13,845 frees, 23,650,726 bytes allocated ==29207== ==29207== LEAK SUMMARY: ==29207== definitely lost: 552 bytes in 7 blocks ==29207== indirectly lost: 104 bytes in 4 blocks ==29207== possibly lost: 12 bytes in 1 blocks ==29207== still reachable: 99,746 bytes in 1,106 blocks ==29207== suppressed: 0 bytes in 0 blocks ==29207== Rerun with --leak-check=full to see details of leaked memory ==29207== ==29207== For counts of detected and suppressed errors, rerun with: -v ==29207== Use --track-origins=yes to see where uninitialised values come from ==29207== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 20 from 5) Floating point exception (core dumped)
I am running a locally compiled SDL 1.2.15. I also tried the stock 1.2.14-6 installed via apt and get the exact same behavior.
I am not sure how to get the value of SDL_VIDEODRIVER other than writing a small program that does getenv("SDL_VIDEODRIVER") and outputs that. When I tried doing that the value was blank. I am not sure what other info would be useful, but if you give me a list of stuff you want I'll be happy to get you the answers :)
comment:9 by , 12 years ago
Could you try editing config.h (after it has been created by configure) to remove the lines defining USE_ARM_SCALER_ASM, USE_ARM_SOUND_ASM, USE_ARM_SMUSH_ASM and USE_ARM_GFX_ASM and then rebuild? (But be careful you don't re-run configure and undo the changes in config.h)
That disables our custom ARM asm, which is a potential cause of this crash.
comment:10 by , 12 years ago
Hi wjpalenstijn, I did so and get the same crash (floating point exception) & valgrind output as previously.
comment:11 by , 12 years ago
katiahayati: Could you try running this under the GNU Debugger, gdb. Do this by running "gdb ./scummvm" and then when the crash occurs, you will be dropped to the gdb command line. Do the command "bt" to get a backtrace of where this is occuring and then paste the backtrace output to here... This will help us understand where the crash is occuring from.
comment:12 by , 12 years ago
hayati@localhost:~/git/scummvm$ gdb ./scummvm GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-linux-gnueabihf". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>... Reading symbols from /home/hayati/git/scummvm/scummvm...done. (gdb) run Starting program: /home/hayati/git/scummvm/scummvm [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". [New Thread 0x76a47450 (LWP 29588)] [New Thread 0x71c37450 (LWP 29589)] [Thread 0x71c37450 (LWP 29589) exited] [New Thread 0x71c37450 (LWP 29590)] WARNING: SDL mixer output buffer size: 1024 differs from desired: 2048!
Program received signal SIGFPE, Arithmetic exception. __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S:47 47 ../ports/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S: No such file or directory. (gdb) bt #0 __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S:47 #1 0x76f45650 in raise (sig=8) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:46 #2 0x76d16f96 in __aeabi_ldiv0 () from /lib/arm-linux-gnueabihf/libgcc_s.so.1 #3 0x00bfc0c0 in OpenGLGraphicsManager::refreshCursorScale (this=0x1260d88) at backends/graphics/opengl/opengl-graphics.cpp:838 #4 0x00bfd346 in OpenGLGraphicsManager::loadGFXMode (this=0x1260d88) at backends/graphics/opengl/opengl-graphics.cpp:1216 #5 0x00bfece8 in OpenGLSdlGraphicsManager::loadGFXMode (this=0x1260d88) at backends/graphics/openglsdl/openglsdl-graphics.cpp:389 #6 0x00bfa9d8 in OpenGLGraphicsManager::endGFXTransaction (this=0x1260d88) at backends/graphics/opengl/opengl-graphics.cpp:287 #7 0x0000cf7e in OSystem_SDL::setGraphicsMode (this=0x122b008, mode=1) at backends/platform/sdl/sdl.cpp:584 #8 0x00ccb96c in OSystem::setGraphicsMode (this=0x122b008, name=0x1233d84 "normal") at common/system.cpp:109 #9 0x0000eb56 in setupGraphics (system=...) at base/main.cpp:251 #10 0x0000f404 in scummvm_main (argc=1, argv=0x7efff744) at base/main.cpp:413 #11 0x0000d92a in main (argc=1, argv=0x7efff744) at backends/platform/sdl/posix/posix-main.cpp:45
comment:13 by , 12 years ago
Hmm... That's odd. That looks like a floating point exception from doing the divison in OpenGLGraphicsManager::refreshCursorScale in file backends/graphics/opengl/opengl-graphics.cpp line 838: uint screenScaleFactorX = _videoMode.hardwareWidth * 10000 / _videoMode.screenWidth;
But that should be an integer divison AFAIK...
katiahayati: Could you look at either using GDB to set a breakpoint at the start of this function and then use the command line to print the value of these variables being divided i.e. the screen width and height.... or if that is tricky, you can do it by adding debug(1, "_videoMode.hardwareWidth: %d", _videoMode.hardwareWidth); and similar before the statement to output via the ScummVM debug channels: http://wiki.scummvm.org/index.php/Debugging_ScummVM
P.S. Since you appear to be a capable programmer, feel free to pop into our development channel at #scummvm on Freenode if you want to help with the more technical side of the project! :)
comment:14 by , 12 years ago
It seems you're currently using an opengl scaler. Those are still a bit unstable and untested, so it's better to stick with other scalers. (Or no scaler at all for testing.)
comment:15 by , 12 years ago
As wjp said, OpenGL support is still a little bit untested... so testing and debug is helpful! :)
But if you want to to avoid this, you should pass "--disable-opengl" to configure and that should remove this code...
comment:16 by , 12 years ago
wjpalenstijn, tdhs: OK, I'll do both :) I'll put in some debugging and report back, and also try disabling OpenGL and see what happens.
comment:17 by , 12 years ago
tdhs: It's normal for integer division (or mod) by zero to trigger an FPE, by the way.
comment:18 by , 12 years ago
wjp: OK... but still a little counterintuitive for a integer division to raise an FPE! :)
Looking at this code, it would be worth adding a debug statement to the initSize() function to output the parameters, especially width and height... as you have indicated, it is likely that width is zero at this point... which shouldn't happen. Maybe we should have assertions for this?
comment:19 by , 12 years ago
Disabling OpenGL side (with all other disables on this thread also applied):
now the GUI starts, but when I try to start a game it crashes with SIGILL.
valgrind:
hayati@localhost:~/git/clean/scummvm$ valgrind ./scummvm ==18895== Memcheck, a memory error detector ==18895== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==18895== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==18895== Command: ./scummvm ==18895== WARNING: SDL mixer output buffer size: 1024 differs from desired: 2048! WARNING: unknown gfx mode 1! ==18895== Syscall param writev(vector[...]) points to uninitialised byte(s) ==18895== at 0x4AD8276: __libc_do_syscall (libc-do-syscall.S:47) ==18895== by 0x4B4D143: writev (writev.c:56) ==18895== by 0x48BCF4D: ??? (in /usr/lib/arm-linux-gnueabihf/libxcb.so.1.1.0) ==18895== Address 0x4c2b9a3 is 19 bytes inside a block of size 16,384 alloc'd ==18895== at 0x482C778: calloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so) ==18895== WARNING: Could not find theme 'scummmodern' falling back to builtin! User picked target 'kq5' (gameid 'sci')... Looking for a plugin supporting this gameid... SCI [SCI0, SCI01, SCI10, SCI11] Starting 'Sierra SCI Game' disInstr(thumb): unhandled instruction: 0xC000 0xE59D ==18895== valgrind: Unrecognised instruction at address 0xc964e1. ==18895== at 0xC964E0: ??? (in /home/hayati/git/clean/scummvm/scummvm) ==18895== Your program just tried to execute an instruction that Valgrind ==18895== did not recognise. There are two possible reasons for this. ==18895== 1. Your program has a bug and erroneously jumped to a non-code ==18895== location. If you are running Memcheck and you just saw a ==18895== warning about a bad jump, it's probably your program's fault. ==18895== 2. The instruction is legitimate but Valgrind doesn't handle it, ==18895== i.e. it's Valgrind's fault. If you think this is the case or ==18895== you are not sure, please let us know and we'll try to fix it. ==18895== Either way, Valgrind will now raise a SIGILL signal which will ==18895== probably kill your program. ==18895== ==18895== Process terminating with default action of signal 4 (SIGILL) ==18895== Illegal opcode at address 0xC964E1 ==18895== at 0xC964E0: ??? (in /home/hayati/git/clean/scummvm/scummvm) ==18895== ==18895== HEAP SUMMARY: ==18895== in use at exit: 2,372,436 bytes in 6,794 blocks ==18895== total heap usage: 30,701 allocs, 23,907 frees, 6,447,438 bytes allocated ==18895== ==18895== LEAK SUMMARY: ==18895== definitely lost: 69 bytes in 3 blocks ==18895== indirectly lost: 104 bytes in 4 blocks ==18895== possibly lost: 26,071 bytes in 1,270 blocks ==18895== still reachable: 2,346,192 bytes in 5,517 blocks ==18895== suppressed: 0 bytes in 0 blocks ==18895== Rerun with --leak-check=full to see details of leaked memory ==18895== ==18895== For counts of detected and suppressed errors, rerun with: -v ==18895== Use --track-origins=yes to see where uninitialised values come from ==18895== ERROR SUMMARY: 32 errors from 1 contexts (suppressed: 83 from 5) Killed
gdb:
hayati@localhost:~/git/clean/scummvm$ gdb ./scummvm GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-linux-gnueabihf". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>... Reading symbols from /home/hayati/git/clean/scummvm/scummvm...done. (gdb) run Starting program: /home/hayati/git/clean/scummvm/scummvm [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". [New Thread 0x76c25460 (LWP 19545)] [New Thread 0x71d02460 (LWP 19546)] [Thread 0x71d02460 (LWP 19546) exited] [New Thread 0x71d02460 (LWP 19548)] WARNING: SDL mixer output buffer size: 1024 differs from desired: 2048! WARNING: unknown gfx mode 1! WARNING: Could not find theme 'scummmodern' falling back to builtin! User picked target 'kq5' (gameid 'sci')... Looking for a plugin supporting this gameid... SCI [SCI0, SCI01, SCI10, SCI11] Starting 'Sierra SCI Game'
Program received signal SIGILL, Illegal instruction. [Switching to Thread 0x71d02460 (LWP 19548)] 0x01436358 in ?? () (gdb) bt #0 0x01436358 in ?? () Cannot access memory at address 0x3e8 #1 0x00c96038 in Audio::CopyRateConverter<true, true>::~CopyRateConverter ( this=0xf2d4b0, __in_chrg=<optimized out>) at audio/rate_arm.cpp:389 Backtrace stopped: previous frame inner to this frame (corrupt stack?)
comment:20 by , 12 years ago
I also added some debugging. Both the height and width are 0. I'll add some extra debugging to the init function as suggested.
diff --git a/backends/graphics/opengl/opengl-graphics.cpp b/backends/graphics/opengl/opengl-graphi index 48e2663..94a9928 100644 --- a/backends/graphics/opengl/opengl-graphics.cpp +++ b/backends/graphics/opengl/opengl-graphics.cpp @@ -830,6 +830,9 @@ void OpenGLGraphicsManager::refreshCursor() { }
void OpenGLGraphicsManager::refreshCursorScale() { + debug(1, "_videoMode.hardwareWidth:%d", _videoMode.hardwareWidth); + debug(1, "_videoMode.hardwareHeight:%d", _videoMode.hardwareHeight); + // Calculate the scale factors of the screen. // We also totally ignore the aspect of the overlay cursor, since aspect // ratio correction only applies to the game screen.
comment:21 by , 12 years ago
width and height are also 0 in initSize:
diff --git a/backends/graphics/opengl/opengl-graphics.cpp b/backends/graphics/opengl/opengl-graphi index 48e2663..f99e7cd 100644 --- a/backends/graphics/opengl/opengl-graphics.cpp +++ b/backends/graphics/opengl/opengl-graphics.cpp @@ -191,6 +191,8 @@ Graphics::PixelFormat OpenGLGraphicsManager::getScreenFormat() const {
void OpenGLGraphicsManager::initSize(uint width, uint height, const Graphics::PixelFormat *format assert(_transactionMode == kTransactionActive); + debug(1, "width: %d", width); + debug(1, "height: %d", height);
hayati@localhost:~/git/scummvm$ ./scummvm -d 11 Debuglevel (from command line): 11 Output sample rate: 22050 Hz Output buffer size: 1024 samples WARNING: SDL mixer output buffer size: 1024 differs from desired: 2048! switching to OpenGL graphics width: 0 height: 0 _videoMode.hardwareWidth:0 _videoMode.hardwareHeight:0 Floating point exception (core dumped)
comment:22 by , 12 years ago
OK, so I don't know if this is helpful, but here goes.
When you *don't* disable OpenGL:
- if you don't pass in an explicit gfx_mode at the command line, lines 162-180 in backends/platform/sdl/sdl.cpp don't get executed, so at the end of that function you have a SurfaceSDL graphics manager instead of an OpenGL graphics manager.
- Which means that the code switching graphics manager, beginning at line 529 of the same file and labeled "very hacky" :), *does* get executed. It then fails in endGFXTransaction because there was no previous state to look at and so a bunch of places that assume non-0 width and height just die. Incidentally, if you just add some code to these places to do nothing if width == 0 && height == 0, they don't die & happily go on.
If you *do* pass in an explicit gfx_mode, like I did in comment 1, then we correctly initialize an OpenGL graphics manager from the get go and don't go through this switching code and the GUI loads properly.
There's still an audio-related crash that happens after that when you try to load a game, but that seems like a separate issue.
comment:23 by , 12 years ago
For the audio error, copying audio/rate.cpp to audio/rate_arm.cpp is a fine workaround for now :)
comment:24 by , 12 years ago
katiahayati: Thank you very much for this. It is extremely helpful and I hope the Core Team do some work to improve the GraphicsManager/SDL/OpenGL backend shared code. As for the audio issue, that sounds like our audio rate converter code c implementation is fine, but the optimised ARM assembly version is buggy :/
If you can see a fix for either of these issues, then please submit it as a patch to the project as a Github Pull Request at https://github.com/scummvm/scummvm If you want to talk about this or need some help/discussion, feel free to ask in the development IRC channel #scummvm on freenode.
Thanks for your efforts so far in any case.
comment:25 by , 12 years ago
Indeed, many thanks for the debugging. This mess is a large part of the reason why we've been disabling OpenGL support in all the stable releases so far, unfortunately.
The ARM rate convertor code calls back into C++, so it's the code most likely to break if the ABI changes, but it doesn't involve any FP code so that's kind of mysterious still..
comment:26 by , 12 years ago
Oh, maybe the ARM thing is a Thumb-2 issue, since it's Ubuntu and there's a MOV/LDR PC pair for that call..
comment:27 by , 12 years ago
fuzzie: According to this: https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
<snip> In a system (like Ubuntu lucid) which contains a mixture of Thumb and ARM code, MOV pc, lr is usually not safe - BX lr should be used instead. However, this is not compatible with ARMv4 or earlier (used by Debian), so macros/#ifdefs may be needed. </snip>
So we may need to detect the ARM version using the macros indicated and switch between MOV and BX usage based on this with an ifdef ?
According to this, LDR should be unaffected...
Or is this a more complex issue?
comment:28 by , 12 years ago
Don't ask me :-) If someone could confirm that fixing it as described on that wiki page works, then that would be a good start.
comment:29 by , 11 years ago
| Component: | --Unset-- → Ports |
|---|
comment:30 by , 7 years ago
| Owner: | set to |
|---|---|
| Resolution: | → outdated |
| Status: | new → closed |
Reviewing this ticket in preparation for the next release, as it was referenced from a more recently updated ticket.
OpenGL has been enabled and working for some time, and the ARM sound code has been disabled since 2015, so this ticket appears to be outdated at this point.
comment:31 by , 6 years ago
| Component: | Ports → Port: Linux |
|---|
If I start scummvm with a scaler option, this problem goes away. Eg ./scummvm -g3x will start. But, it will then crash with an illegal instruction error when I try to load any game.
Valgrind output for Zak:
hayati@localhost:~/git/scummvm$ valgrind ./scummvm -g3x ==6848== Memcheck, a memory error detector ==6848== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==6848== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==6848== Command: ./scummvm -g3x ==6848== WARNING: SDL mixer output buffer size: 1024 differs from desired: 2048! ==6848== Syscall param writev(vector[...]) points to uninitialised byte(s) ==6848== at 0x4B02276: __libc_do_syscall (libc-do-syscall.S:47) ==6848== by 0x4B77143: writev (writev.c:56) ==6848== by 0x4E9DF4D: ??? (in /usr/lib/arm-linux-gnueabihf/libxcb.so.1.1.0) ==6848== Address 0x52f63f3 is 19 bytes inside a block of size 16,384 alloc'd ==6848== at 0x482C778: calloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so) ==6848== WARNING: Could not find theme 'scummmodern' falling back to builtin! ==6848== Conditional jump or move depends on uninitialised value(s) ==6848== at 0x4878298: ??? (in /usr/lib/arm-linux-gnueabihf/libSDL-1.2.so.0.11.3) ==6848== User picked target 'zak-v2' (gameid 'zak')... Looking for a plugin supporting this gameid... SCUMM [v0-v6 games] Starting 'Zak McKracken and the Alien Mindbenders' disInstr(thumb): unhandled instruction: 0xC000 0xE59D ==6848== valgrind: Unrecognised instruction at address 0x290319. ==6848== at 0x290318: ??? (in /home/hayati/git/scummvm/scummvm) ==6848== Your program just tried to execute an instruction that Valgrind ==6848== did not recognise. There are two possible reasons for this. ==6848== 1. Your program has a bug and erroneously jumped to a non-code ==6848== location. If you are running Memcheck and you just saw a ==6848== warning about a bad jump, it's probably your program's fault. ==6848== 2. The instruction is legitimate but Valgrind doesn't handle it, ==6848== i.e. it's Valgrind's fault. If you think this is the case or ==6848== you are not sure, please let us know and we'll try to fix it. ==6848== Either way, Valgrind will now raise a SIGILL signal which will ==6848== probably kill your program. ==6848== ==6848== Process terminating with default action of signal 4 (SIGILL) ==6848== Illegal opcode at address 0x290319 ==6848== at 0x290318: ??? (in /home/hayati/git/scummvm/scummvm) ==6848== ==6848== HEAP SUMMARY: ==6848== in use at exit: 8,402,478 bytes in 4,891 blocks ==6848== total heap usage: 28,821 allocs, 23,930 frees, 13,985,528 bytes allocated ==6848== ==6848== LEAK SUMMARY: ==6848== definitely lost: 8 bytes in 1 blocks ==6848== indirectly lost: 104 bytes in 4 blocks ==6848== possibly lost: 26,103 bytes in 1,270 blocks ==6848== still reachable: 8,376,263 bytes in 3,616 blocks ==6848== suppressed: 0 bytes in 0 blocks ==6848== Rerun with --leak-check=full to see details of leaked memory ==6848== ==6848== For counts of detected and suppressed errors, rerun with: -v ==6848== Use --track-origins=yes to see where uninitialised values come from ==6848== ERROR SUMMARY: 45 errors from 2 contexts (suppressed: 5 from 3) Killed
Valgrind output for kq5:
hayati@localhost:~/git/scummvm$ valgrind ./scummvm -g3x ==7083== Memcheck, a memory error detector ==7083== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==7083== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==7083== Command: ./scummvm -g3x ==7083== WARNING: SDL mixer output buffer size: 1024 differs from desired: 2048! ==7083== Syscall param writev(vector[...]) points to uninitialised byte(s) ==7083== at 0x4B02276: __libc_do_syscall (libc-do-syscall.S:47) ==7083== by 0x4B77143: writev (writev.c:56) ==7083== by 0x4E9DF4D: ??? (in /usr/lib/arm-linux-gnueabihf/libxcb.so.1.1.0) ==7083== Address 0x52f63f3 is 19 bytes inside a block of size 16,384 alloc'd ==7083== at 0x482C778: calloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so) ==7083== WARNING: Could not find theme 'scummmodern' falling back to builtin! ==7083== Conditional jump or move depends on uninitialised value(s) ==7083== at 0x4878298: ??? (in /usr/lib/arm-linux-gnueabihf/libSDL-1.2.so.0.11.3) ==7083== User picked target 'kq5' (gameid 'sci')... Looking for a plugin supporting this gameid... SCI [SCI0, SCI01, SCI10, SCI11] Starting 'Sierra SCI Game' disInstr(thumb): unhandled instruction: 0xC000 0xE59D ==7083== valgrind: Unrecognised instruction at address 0x290319. ==7083== at 0x290318: ??? (in /home/hayati/git/scummvm/scummvm) ==7083== Your program just tried to execute an instruction that Valgrind ==7083== did not recognise. There are two possible reasons for this. ==7083== 1. Your program has a bug and erroneously jumped to a non-code ==7083== location. If you are running Memcheck and you just saw a ==7083== warning about a bad jump, it's probably your program's fault. ==7083== 2. The instruction is legitimate but Valgrind doesn't handle it, ==7083== i.e. it's Valgrind's fault. If you think this is the case or ==7083== you are not sure, please let us know and we'll try to fix it. ==7083== Either way, Valgrind will now raise a SIGILL signal which will ==7083== probably kill your program. ==7083== ==7083== Process terminating with default action of signal 4 (SIGILL) ==7083== Illegal opcode at address 0x290319 ==7083== at 0x290318: ??? (in /home/hayati/git/scummvm/scummvm) ==7083== ==7083== HEAP SUMMARY: ==7083== in use at exit: 8,776,511 bytes in 6,736 blocks ==7083== total heap usage: 31,235 allocs, 24,499 frees, 15,064,625 bytes allocated ==7083== ==7083== LEAK SUMMARY: ==7083== definitely lost: 8 bytes in 1 blocks ==7083== indirectly lost: 104 bytes in 4 blocks ==7083== possibly lost: 26,103 bytes in 1,270 blocks ==7083== still reachable: 8,750,296 bytes in 5,461 blocks ==7083== suppressed: 0 bytes in 0 blocks ==7083== Rerun with --leak-check=full to see details of leaked memory ==7083== ==7083== For counts of detected and suppressed errors, rerun with: -v ==7083== Use --track-origins=yes to see where uninitialised values come from ==7083== ERROR SUMMARY: 50 errors from 2 contexts (suppressed: 5 from 3) Killed