Attempting double-free on IOS with SDL

[GoogleCodeExporter]

Hi , 

I am not sure if this issue is with the address-sanitizer or with the SDL lib 
itself. But I would appreciate any help.

I have compiled latest llvm and clang from the svn repository under OSX 10.9 .
All the address-sanitizer tests ran correctly. I tried the sanitizer with an 
IOS app that I am making. It is IOS 7.0 with SDL lib. 

I have compiled the app with -fsanitize=address for the simulator architecture 
x86 .
When I do the asan_symbolize.py / < log | c++filt
I got this:

=================================================================
==11907==ERROR: AddressSanitizer: attempting double-free on 0x0ab7aef0 in 
thread T0:

    #0 0x11e035 in wrap_free _asan_rtl_
    #1 0x5f764 in SDL_DestroySemaphore SDL_syssem.c:119
    #2 0x5f1a0 in SDL_CreateThread SDL_thread.c:382
    #3 0x5fd62 in SDL_TimerInit SDL_timer.c:233
    #4 0xef2e in SDL_InitSubSystem SDL.c:158
    #5 0x2d2f in Game::init Game.cpp:15
    #6 0x5a9d in SDL_main main.cpp:26
    #7 0x95e80 in -[SDLUIKitDelegate postFinishLaunch] SDL_uikitappdelegate.m:189
    #8 0xa3512b in __NSFireDelayedPerform (in Foundation) + 371
    #9 0x29dcbd5 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ (in CoreFoundation) + 21
    #10 0x29dc5bc in __CFRunLoopDoTimer (in CoreFoundation) + 1180
    #11 0x29c4627 in __CFRunLoopRun (in CoreFoundation) + 1815
    #12 0x29c3ac2 in CFRunLoopRunSpecific (in CoreFoundation) + 466
    #13 0x29c38da in CFRunLoopRunInMode (in CoreFoundation) + 122
    #14 0x45d19e1 in GSEventRunModal (in GraphicsServices) + 191
    #15 0x45d1808 in GSEventRun (in GraphicsServices) + 103
    #16 0xe0fd3a in UIApplicationMain (in UIKit) + 1224
    #17 0x959aa in main SDL_uikitappdelegate.m:59
    #18 0x2fa770c in start (in libdyld.dylib) + 0
    #19 0x0 in 0x0

0x0ab7aef0 is located 0 bytes inside of 28-byte region [0x0ab7aef0,0x0ab7af0c)
freed by thread T0 here:
==11907==AddressSanitizer CHECK failed: 
/Users/sabotage3d/DEV/libs/llvm/projects/compiler-unsigned short 
restrict/lib/asan/asan_allocator2.cc:237 "((id)) != (0)" (0x0, 0x0)

    #0 0x126de7 in __asan::AsanCheckFailed _asan_rtl_
    #1 0x12ac21 in __sanitizer::CheckFailed sanitizer_common.cc:76

Any ideas ?

Thanks in advance,

Alex

Original issue reported on code.google.com by sabotag...@gmail.com on 8 Mar 2014 at 9:04

[GoogleCodeExporter]

I would suggest to insert a printf into DL_DestroySemaphore from 
SDL_syssem.c:119
(and the matching code that creates such objects) and see if the objects are 
indeed
deleted twice.

It's not good that asan crashes in the CHECK failure, 
so indeed a standalone repro is most welcome.

Original comment by konstant...@gmail.com on 11 Mar 2014 at 1:51

[GoogleCodeExporter]

I was able to blacklist some of the SDL files yesterday and after a few tries 
it seems the error is gone. Not sure if that is the best practice in this case. 
Now the app just doesn't produce any output and it just exits compiled with 
-fsanitize=address.  Is there a way to keep it going until It finds an error or 
it is not the way to work with address sanitizer. Otherwise to debug a game 
might be really hard.
What is the best way to give you a standalone to reproduce the error,it will 
need the SDL library itself. 

Original comment by sabotag...@gmail.com on 11 Mar 2014 at 2:08

[GoogleCodeExporter]

The best solution is to make a tar.gz with the necessary source files and post 
it along with the command line to build and run the binary. We're also ok with 
downloading additional dependencies if that's as easy as `curl ...; tar -xf 
...`.

Please make sure you don't include proprietary code into the reproducer.

I don't think blacklisting anything will help, because detecting double-free 
errors doesn't require ASan instrumentation, it's handled by the runtime 
library.
Have you tried running the code under libgmalloc?

Original comment by ramosian.glider@gmail.com on 11 Mar 2014 at 2:18

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I am using lldb. The crashes I had were related to my code not SDL. But when I 
changed the compiler to the latest clang. I had a crash with SDL but it was 
pointing to other files. I changed the archs only to 32 bit. And it is no 
longer crashing in lldb. It seems that is a bit random but address sanitizer 
was constantly giving the error. Until yesterday when I tried blacklist. It 
might be something else I will try to reproduce the problem in a clean example 
but I am not sure if you can test it under ios as you would need the static 
compiled library of SDL for IOS 7.0 .

Original comment by sabotag...@gmail.com on 11 Mar 2014 at 2:35

[GoogleCodeExporter]

I'm asking because libglmalloc also allows you to detect double free errors. If 
libglmalloc also reports a double free, the problem is really in the code 
(either yours, or SDL), not ASan.

Regarding reproducibility, ASan replaces the system allocator with a hardened 
one, which improves the chance to hit a memory error.

Original comment by ramosian.glider@gmail.com on 11 Mar 2014 at 2:39

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

You are right. I ran a few tests on a simple cases. The IOS Opengl Template  
and the SDL default Template ran without problems correctly through 
-fsanitize=address while my project is crashing randomly. I am still trying to 
isolate the issue in my project.

Original comment by sabotag...@gmail.com on 11 Mar 2014 at 10:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ok I think I found the issue in a simple example if I initialize SDL with
if (SDL_Init(SDL_INIT_EVERYTHING) < 0) it crashes and it produces the same 
errors 
while doing the same only with the video module seems fine 
if (SDL_Init(SDL_INIT_VIDEO) < 0) no errors . I will flag it with the SDL guys.

SDL 2.0.2 

Original comment by sabotag...@gmail.com on 11 Mar 2014 at 10:59

[GoogleCodeExporter]

Can you please post the link to the SDL bug report when you file one?
We're curious what's going on there.

Original comment by ramosian.glider@gmail.com on 12 Mar 2014 at 7:43

[GoogleCodeExporter]

Hi again so far I have submitted the problem to the SDL mailing list.
This is the topic. I am still trying to confirm the problem with the SDL guys.

http://forums.libsdl.org/viewtopic.php?t=10112&sid=e7efecbaea510015c43f17994bc1b
5d6

Original comment by sabotag...@gmail.com on 17 Mar 2014 at 10:08

[GoogleCodeExporter]

I did some tests, after commenting the line in SDL_DestroySemaphore 
SDL_syssem.c:119
Everything seems to be smooth no crashes or problems. The SDL guys ran some 
tests as well but they couldn't find the bug they said the stack looks good. 

If you are interested these were the problematic files.

https://hg.libsdl.org/SDL/file/a60eaa04d3fb/src/thread/pthread/SDL_syssem.c

https://hg.libsdl.org/SDL/file/a60eaa04d3fb/src/thread/generic/SDL_syssem.c

The error seems to be happening in this one /src/thread/generic/SDL_syssem.c 
line 119

Original comment by sabotag...@gmail.com on 19 Mar 2014 at 12:42