This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 478664 - rocksndiamonds crash (free(): invalid pointer) in level 6 of Aaron Davidson's tutorial
rocksndiamonds crash (free(): invalid pointer) in level 6 of Aaron Davidson's...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: rocksndiamonds (Show other bugs)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Tom "spot" Callaway
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-02 21:31 EST by Kevin Kofler
Modified: 2009-01-16 18:46 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-16 18:43:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kevin Kofler 2009-01-02 21:31:59 EST
Description of problem:
Rocksndiamonds reproducibly crashes in level 6 when moving to the upper right of the screen (the area with the yam-yam robots).

Version-Release number of selected component (if applicable):
rocksndiamonds-3.2.3-3.fc9.2.i386

How reproducible:
Always

Steps to Reproduce:
1. Start level 6.
2. Go all the way to the right.
3. Go up until it crashes.
  
Actual results:
*** glibc detected *** rocksndiamonds: free(): invalid pointer: 0x0a4f9320 ***
(The actual address varies.)

Expected results:
No crash.

Additional info:
======= Backtrace: =========
/lib/libc.so.6[0x8b6874]
/lib/libc.so.6(cfree+0x96)[0x8b88d6]
/usr/lib/libSDL_mixer-1.2.so.0[0x757c513]
/usr/lib/libSDL_mixer-1.2.so.0[0x757ded1]
/usr/lib/libSDL_mixer-1.2.so.0[0x757f558]
/usr/lib/libSDL-1.2.so.0[0x73719d2]
/usr/lib/libSDL-1.2.so.0[0x73795bb]
/usr/lib/libSDL-1.2.so.0[0x73c7dcd]
/lib/libpthread.so.0[0x9ec32f]
/lib/libc.so.6(clone+0x5e)[0x92720e]

This might be a bug in SDL_mixer. I'm trying to get a better backtrace (with debugging symbols in it).
Comment 1 Kevin Kofler 2009-01-02 21:37:58 EST
It behaves differently in GDB, but I managed to crash it in GDB too:

*** glibc detected *** /usr/bin/rocksndiamonds: free(): invalid next size (fast): 0x0aa957c0 ***
======= Backtrace: =========
/lib/libc.so.6[0x8b6874]
/lib/libc.so.6(cfree+0x96)[0x8b88d6]
/usr/lib/libSDL_mixer-1.2.so.0[0x757c513]
/usr/lib/libSDL_mixer-1.2.so.0[0x757ded1]
/usr/lib/libSDL_mixer-1.2.so.0[0x757f558]
/usr/lib/libSDL-1.2.so.0[0x73719d2]
/usr/lib/libSDL-1.2.so.0[0x73795bb]
/usr/lib/libSDL-1.2.so.0[0x73c7dcd]
/lib/libpthread.so.0[0x9ec32f]
/lib/libc.so.6(clone+0x5e)[0x92720e]

(gdb) bt
#0  0x00110416 in __kernel_vsyscall ()
#1  0x00873660 in raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64  
#2  0x00875028 in abort () at abort.c:88           
#3  0x008b064d in __libc_message (do_abort=<value optimized out>, 
    fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:170
#4  0x008b6874 in malloc_printerr (action=<value optimized out>,
    str=<value optimized out>, ptr=<value optimized out>) at malloc.c:5949
#5  0x008b88d6 in __libc_free (mem=<value optimized out>) at malloc.c:3625
#6  0x0757c513 in _Eff_PositionDone (channel=<value optimized out>, udata=Couldnot find the frame base for "_Eff_PositionDone".
)
    at ./effect_position.c:107
#7  0x0757ded1 in _Mix_remove_all_effects (channel=<value optimized out>,
    e=<value optimized out>) at ./mixer.c:1219
#8  0x0757f558 in mix_channels (udata=Could not find the frame base for "mix_channels".
) at ./mixer.c:225
#9  0x073719d2 in SDL_RunAudio (audiop=<value optimized out>)
    at src/audio/SDL_audio.c:198
#10 0x073795bb in SDL_RunThread (data=Could not find the frame base for "SDL_RunThread".
) at src/thread/SDL_thread.c:202
#11 0x073c7dcd in RunThread (data=Could not find the frame base for "RunThread".
) at src/thread/pthread/SDL_systhread.c:47
#12 0x009ec32f in start_thread (arg=<value optimized out>)
    at pthread_create.c:297
#13 0x0092720e in clone () from /lib/libc.so.6
Comment 2 Kevin Kofler 2009-01-02 21:42:07 EST
Valgrind reports this as the probable cause:

==29972== Invalid write of size 4                                               
==29972==    at 0x757B5AF: Mix_SetPosition (effect_position.c:1526)             
==29972==    by 0x757B72F: Mix_SetPosition (effect_position.c:1383)             
==29972==    by 0x757C3FF: (within /usr/lib/libSDL_mixer-1.2.so.0.2.6)
==29972==    by 0x80A538E: StopSoundExt (sound.c:2177)
==29972==    by 0x80A6601: HandleAnimation (toons.c:360)
==29972==    by 0x806861A: InitMovingField (game.c:3107)
==29972==    by 0x806887F: CheckExitSP (game.c:12288)
==29972==    by 0x807D053: StartMoving (game.c:5560)
==29972==    by 0x808009B: GameActions_RND (game.c:10332)
==29972==    by 0x8083B1F: CopyBrushExt (editor.c:8400)
==29972==    by 0x805C82C: drawPlayerSetupInputInfo (screens.c:4106)
==29972==    by 0x80511C4: PlayMenuMusic (tools.c:6212)
==29972==  Address 0x46dc814 is 4 bytes before a block of size 48 alloc'd
==29972==    at 0x4006AEE: malloc (vg_replace_malloc.c:207)
==29972==    by 0x757B71B: Mix_SetPosition (effect_position.c:1382)
==29972==    by 0x757C3FF: (within /usr/lib/libSDL_mixer-1.2.so.0.2.6)
==29972==    by 0x80A538E: StopSoundExt (sound.c:2177)
==29972==    by 0x80A6601: HandleAnimation (toons.c:360)
==29972==    by 0x806861A: InitMovingField (game.c:3107)
==29972==    by 0x806887F: CheckExitSP (game.c:12288)
==29972==    by 0x807D053: StartMoving (game.c:5560)
==29972==    by 0x808009B: GameActions_RND (game.c:10332)
==29972==    by 0x8083B1F: CopyBrushExt (editor.c:8400)
==29972==    by 0x805C82C: drawPlayerSetupInputInfo (screens.c:4106)
==29972==    by 0x80511C4: PlayMenuMusic (tools.c:6212)


And then it triggers this (when moving back down and to the left, which is also how I reproduced the crash in GDB):
valgrind: m_mallocfree.c:194 (mk_plain_bszB): Assertion 'bszB != 0' failed.
==29972==    at 0x3801A3FD: report_and_quit (m_libcassert.c:140)           
==29972==    by 0x3801A6EE: vgPlain_assert_fail (m_libcassert.c:200)       
==29972==    by 0x38024539: vgPlain_arena_free (m_mallocfree.c:194)        
==29972==    by 0x380369B8: vgPlain_cli_free (replacemalloc_core.c:108)    
==29972==    by 0x38001CEF: die_and_free_mem (mc_malloc_wrappers.c:122)    
==29972==    by 0x380027A7: vgMemCheck_free (mc_malloc_wrappers.c:319)     
==29972==    by 0x38039102: vgPlain_scheduler (scheduler.c:1269)           
==29972==    by 0x3804CCC8: run_a_thread_NORETURN (syswrap-linux.c:89)     
==29972==    by 0x3804CF92: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:212)                                                                           
==29972==    by 0x38074558: (within /usr/lib/valgrind/x86-linux/memcheck)       

sched status:
  running_tid=2

Thread 1: status = VgTs_Yielding
==29972==    at 0x80803CE: ??? (game.c:10283)
==29972==    by 0x8083B1F: CopyBrushExt (editor.c:8400)
==29972==    by 0x805C82C: drawPlayerSetupInputInfo (screens.c:4106)
==29972==    by 0x80511C4: PlayMenuMusic (tools.c:6212)
==29972==    by 0x804A33A: getNewArtworkIdentifier (init.c:4730)
==29972==    by 0x85F5D5: (below main) (libc-start.c:220)

Thread 2: status = VgTs_Runnable
==29972==    at 0x400590A: free (vg_replace_malloc.c:323)
==29972==    by 0x757F524: Mix_QuickLoad_WAV (mixer.c:536)
==29972==    by 0x73719D1: SDL_RunAudio (SDL_audio.c:198)
==29972==    by 0x73795BA: SDL_RunThread (SDL_thread.c:202)
==29972==    by 0x73C7DCC: RunThread (SDL_systhread.c:47)
==29972==    by 0x9EC32E: start_thread (pthread_create.c:297)
==29972==    by 0x92720D: clone (in /lib/libc-2.8.so)
Comment 3 Tom "spot" Callaway 2009-01-14 15:38:07 EST
Which level set were you using?
Comment 4 Kevin Kofler 2009-01-14 16:44:09 EST
Aaron Davidson's tutorial.
Comment 5 Tom "spot" Callaway 2009-01-14 17:45:27 EST
Okay, please give this build a try:

http://koji.fedoraproject.org/koji/buildinfo?buildID=78538
Comment 6 Kevin Kofler 2009-01-14 17:56:15 EST
That appears to fix it when running the game as is, but Valgrind still finds that same invalid write of size 4 and assertion failure, so I'm afraid I have to think it's only chance that the crash no longer seems to happen, the bug is still there. :-(
Comment 7 Tom "spot" Callaway 2009-01-14 18:05:39 EST
The interesting thing is that upstream doesn't seem to think this is a bug. Looking at the rocksndiamonds code where Valgrind says it goes into SDL:

2169 void StopSoundExt(int nr, int state)
2170 {
2171   SoundControl snd_ctrl;
2172 
2173   if (!audio.sound_available)
2174     return;
2175 
2176   clear_mem(&snd_ctrl, sizeof(SoundControl));   /* to make valgrind happy */
2177 
2178   snd_ctrl.active = FALSE;
2179   snd_ctrl.nr = nr;
2180   snd_ctrl.state = state;
2181 
2182   HandleSoundRequest(snd_ctrl);
2183 }

Accordingly, I'm inclined to push this update to "fix" the bug, as I can no longer make it crash.
Comment 8 Kevin Kofler 2009-01-14 18:14:01 EST
I don't see how a clear_mem is supposed to fix a buffer underflow ("Address 0x46dc814 is 4 bytes before a block of size 48 alloc'd"), but whatever, as long as it doesn't crash anymore...
Comment 9 Fedora Update System 2009-01-15 11:56:17 EST
rocksndiamonds-3.2.6.0-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/rocksndiamonds-3.2.6.0-1.fc9
Comment 10 Fedora Update System 2009-01-15 11:56:20 EST
rocksndiamonds-3.2.6.0-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/rocksndiamonds-3.2.6.0-1.fc10
Comment 11 Fedora Update System 2009-01-16 18:43:45 EST
rocksndiamonds-3.2.6.0-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 12 Fedora Update System 2009-01-16 18:46:11 EST
rocksndiamonds-3.2.6.0-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.